Team SAML single sign-on

This feature may not be available on all plans.

Team Owners can allow, and optionally require, team members to log in to Netlify through their company’s SAML single sign-on (SSO) provider.

Team Owners can configure SSO through an identity provider for one team at a time. If you want to set up SAML SSO for all teams in an organization, then we recommend you check out Organization SAML single sign-on.

Users who log in with Team SSO must have an email address that matches their user ID in your identity provider. For example, a Netlify user with the email address must also have this exact email address in your identity provider. Organization SSO does not support multiple email domains for your users.

SSO not supported for Reviewer role

Although SSO is currently not supported for Reviewers, they can still log in using non-SSO options. To enable SSO for a Reviewer, add them to your team as a Collaborator using your team’s specific email domain.

# Get started

SAML SSO information and settings are found under Team settings > General > Team details > Single sign-on.

To get started, you’ll need to configure SAML support for Netlify with your identity provider. Our SAML help doc provides setup instructions for commonly used identity providers including Google G Suite, Okta, OneLogin, Ping Identity PingOne, and Azure Active Directory. After completing the configuration, your team members will be able to log in to your team using SSO.

The standard Netlify login interface includes a link to log in using SSO.

# Login types

By default, teams with single sign-on enabled allow but do not require team members to log in using SSO. Team Owners can change the allowed login types to require that team members be logged in using SSO in order to access the team. To do this, go to Team settings > General > Team details > Single sign-on and select Edit login types.

Then choose how team members can access your team. You can select All login types allowed, Only SSO allowed (with Owner fallback), or Only SSO allowed (strict).

# All login types allowed

When all login types are allowed, team members will still be able to access your team when logged in with email, GitHub, GitLab, or Bitbucket. SSO becomes a new login option, but it is not required. You might have team members accessing your team with their personal users rather than with users that have company email addresses that you provision using your identity provider.

# Only SSO allowed

The Only SSO allowed option includes two variants for different scopes of enforcement based on team member roles.

  • Only SSO allowed (with Owner fallback): all team members except Owners will be required to log in using SSO to access your team. Team Owners will still be able to log in with email, GitHub, GitLab, or Bitbucket, in case your identity provider has an outage or other issue.
  • Only SSO allowed (strict): all team members, including Owners, will be required to log in using SSO to access your team.

When you set Login types to either of the options above, several things (as outlined below) will happen to ensure that your team can be accessed by only the users you’ve provisioned with your identity provider. To facilitate this you’ll need to enter your company email domain in the form of

In the points below, “affected team members” refers to all non-Owner team members when selecting enforcement with Owner fallback, and to all team members when selecting strict enforcement.

  • Affected team members with email addresses outside of the company email domain will be removed from this team. Before saving this setting you may want to check the email addresses in your team member list and ask team members to ensure their email address is on the company email domain.
  • Remaining affected team members who logged in with email, GitHub, GitLab, or Bitbucket will be denied access to the team until they sign out and then log back in using SSO. You may want to let your team members know to expect this, especially if they are a member of other teams where all login types are allowed.
  • API calls using access tokens generated by affected team members will be denied access by default. This applies to both personal access tokens and tokens from authorized applications. You may want to let your team members know to expect this, especially if they generated tokens in the past. If your team needs to use access tokens, there are a couple options:
    • You can select enforcement with Owner fallback which won’t affect access tokens generated by team Owners.
    • Affected team members can generate new tokens and grant SAML access to those tokens.
  • All team members (including Owners) will no longer be able to save changes to their email address or password in their user settings. These changes will need to be made using your identity provider.
  • Team Owners will no longer be able to invite new team members using Netlify. You will need to provision new team members using your identity provider. This will add new team members as Collaborators. Once added, you can change a team member’s permissions if necessary.