NEXT offers the option to configure your own managed identity provider as a single sign-on authentication option for NEXT enterprise workspaces.
Managed identity provider
On NEXT enterprise workspaces, you can bring your organization's identity provider to integrate with directly with NEXT. Using your own organization's identity allows you to delegate authentication and provisioning to your source of truth to increase security and onboard employees faster.
SSO benefits
Single sign-on allows users to log into NEXT with their organization's account. This means for users that they don't have to remember yet another password and for organizations that they don't have to worry about yet another place to manage their users (e.g. when somebody leaves the organization).
NEXT single sign-on is available to NEXT Enterprise workspaces.
User journey during single sign-on
With single sign-on activated, this is the journey of a user:
User sees on the NEXT login page a "Log in with SSO" login button
Clicking that button, the user is forwarded to the organization's identity provider (e.g. Active Directory)
The identity provider authenticates the user and sends the user back to NEXT
NEXT checks if the authenticated user has already an account in NEXT. If not, a new account is created on the fly. This provides seamless access to e.g. new employees.
The user is logged into NEXT
How to set up single sign-on (step-by-step guidance)
NEXT enables single sign-on via SAML, the industry-standard supported by identity providers like Microsoft's Azure Active Directory.
In general terms these are the steps to set up single sign-on:
Step 1 – Find SAML input
Log into NEXT with an administrator account and go to "Settings & Members" > "SSO". Please copy from their the various inputs, like "Entity ID", that you will need to set up your identity provider. For example:
Step 2 – Configure your identity provider
Step 2.1 – Create application in your identity provider
Set up an application for NEXT in your identity provider (e.g. Microsoft's Azure Active Directory). Use above input value for "Entity ID", "Reply URL", etc.
Configure the application logo so that users can identify the application in the application directory (please find the logo attached to this article)
Here an example from Azure Active Directory:
Step 2.2 – Configure the claims provided by the identity provider to NEXT
Claim | Contents | Required? |
NameID | Unique identifier. This must use the "persistent SAML Name ID format." | Required |
role | Initial user role in the NEXT application Each user must have exactly one of the available roles: admin, user, guest This value is only used when initially provisioning a user, afterwards, the user role can be adjusted through NEXT's administrative interface | Optional (default is "user") |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress | Email address of the user for receiving mails. This should be in the regular RFC822 format ( | Required |
Here an example from Azure ActiveDirectory (AD):
Step 2.3 – Assign the users that should be able to use NEXT to the application
Step 3 – Enter metadata URL in NEXT
Get the "Federation Metadata URL" for the application from your identity provider, e.g. for Azure Active Directory:
Copy the metadata URL in the NEXT SSO configuration page.
Please inform NEXT if you wish migrate any non-SSO users to SSO (see below section on "Migrate existing non-SSO users to SSO").
Migrate existing non-SSO users to SSO
If you enable SSO after using NEXT for a while, you might have already users with a NEXT account whom you want to log in with SSO instead of email/password.
In a nutshell: Without SSO, users prove that they own their NEXT account by typing in their email/password. With SSO, users prove ownership via a token granted by the SSO IdP, showing that they own the email address associated to the NEXT account. This means if a user logs in via SSO: NEXT checks if there is already an existing NEXT account with the same email address. If so, it binds the existing NEXT account to the SSO identity. If not, a new NEXT account is created for the user.
Before moving to SSO, please validate the email addresses of all users in the admin pages of the NEXT app. All same email address in NEXT must match the ones registered in their SSO identity.
Additional Considerations
SSO-Only or SSO+non-SSO?
In the default configuration, NEXT manages users in a user directory for you, and you can add SSO as an additional sign-in option for your users. Any existing users can use the user directory, and newly invited users will be added to the NEXT user directory.
Depending on the particular details of your organization however, it could be required to enforce the use of SSO. In this case, users must authenticate through your identity provider. The "Invite user" functionality can be used to send out invitation links to new users (taking into account any configured Signup domain restrictions), but whether the user can accept the invitation depends on whether the account of the user in the identity provider has been configured to allow access to NEXT.
Note that the invitation emails right now do not indicate a SSO-only environment, and will contain a generic "Signup" link.
Note that this will impact also accounts that you might have created for NEXT's Customer Success/Support. There are different options to ensure smooth interactions with NEXT in a SSO-only setup:
You can add the NEXT account to your SSO IdP.
You can sign up for a free NEXT instance and reproduce the issue there. This can then be share with NEXT Support.
You can organize a screen share session with NEXT Customer Success and a user who has SSO access.
SP-Initiated or IdP-Initiated Sign-In
NEXT assumes an SP-initiated sign-in, i.e. users go to NEXT via https://TENANT.nextapp.co, and from there get pointed to the IdP for signing in.
Right now it is not possible to configure the application for a pure IdP-initiated sign-in experience due to technical limitations. In case IdP-initiated sign-in is needed (for example for an application directory for users), the application in the directory should be configured to go to the https://TENANT.nextapp.co URL.
Access Token Expiration
We cannot automatically refresh sessions of users who sign-in via SAML. With the default token expiration time of 1h that would create a rather huge burden for the SSO users: They would need to re-authenticate explicitly every hour of work.
To avoid user frustration, the expiration times for id and access tokens are 8h when SSO via SAML is enabled. Please contact support for any concerns related to this topic.
Role Management
NEXT user roles are managed inside the NEXT administrative interface for existing (and invited) users.
If the IdP includes role claim in the token for a new user NEXT will assign this role to the user. Changing the role claim for an existing user will not propagate the changed role to NEXT.
Signing and Token encryption
NEXT does not support signing (AuthnRequestsSigned and WantAssertionsSigned in the SP SSO descriptor) nor token encryption.
Federation Metadata URL or file?
Typically the federation metadata can be exported from the IdP either as a XML file, or as a "live URL". NEXT generally prefers a live URL, as that means we are not coupled to (nor do we need to be involved) when the enterprise needs to change the metadata. The IdP is already accessible through the internet, so this generally should not be a problem. If there are concerns about exposing the metadata through a public URL, please do contact Customer Success.