Single Sign-on

Single sign-on is an authentication process in which a user can access more than one application by entering a single user ID and password. You can configure multiple applications to use Verify for user authentication and authorization. The users sign in to the target applications by using their Verify account credentials. When authenticated with Verify, users can access any of the applications they are entitled to, within the authenticated session. When the session expires, the users must sign in again through Verify.

To implement single sign-on between Verify and any target application, they must exchange configuration details. You must configure the application in Verify and configure Verify in the target application.

Authentication and authorization

Authentication is verifying the identity of a user; proving that the user is who that person claims to be. Authorization is granting a user access to a resource and defining what that person can do with the resource. Verify supports authentication and authorization by using SAML and OpenID Connect.

Table 1. Comparison summary
	SAML 2.0	OpenID Connect
Description	Security Assertion Markup Language (SAML) is an open standard that provides authentication and authorization. The standard provides a framework for the secure communication of user identities between a service provider and an identity provider.	OpenID Connect is an open standard protocol that combines OpenID authentication and OAuth2.0 authorization capabilities. The standard provides a framework for the secure communication of user identities between a relying party and an OpenID Connect provider.
Use case	Single sign-on for enterprise applications	Single sign-on for enterprise and consumer applications
Supported client types	Web-based	Web-based Mobile or native JavaScript
Data format	XML	JSON
User information or authentication is sent through	A SAML assertion. The assertion contains the following information: Subject (who authenticated) Attributes (information about the person) Issuer (who issued the assertion) Other information about the authentication event	A JSON Web Token (JWT), called an ID token. The token contains the following information: Subject (who authenticated) Issuer (who issued the user claims) Authentication expiry Attributes or user claims (information about the person)¹ Other information about the authentication event
Tokens	Access token	ID token Access token. The access token can be either an opaque string or in JWT format. Refresh token Note: OAuth/OIDC token lengths are not fixed. When storing the access and refresh tokens, allow for variable lengths. If you need to set a maximum length for storage and do not plan to use JWT format access tokens in the future, allow at least 1024 characters for the token length.
Components / Roles	User, who is requesting access. User agent, where the user authenticates; for example, the web browser. Service provider, the application that the user is trying to access. Identity provider, authenticates the user.	User, who is requesting access. User agent, where the user authenticates; for example, the web browser. Relying party or client, the application that the user is trying to access. OpenID Connect provider, authenticates the user and the client.

SAML based single sign-on

The service provider can be any web-based application that requires its users to be authenticated. It is the consumer of the returned user identity information.

The identity provider manages and asserts the user identity.

The user requests access to a protected resource of the service provider through a user agent.
The service provider sends a user authentication request by redirecting the user agent to the identity provider.
The identity provider verifies the identity of the user and generates a SAML assertion that asserts the user identity.
The identity provider packages the assertion in its SAML authentication response to the service provider.

OpenID Connect based single sign-on

The OpenID Connect relying party can be any application that requires its users to be authenticated. It is the consumer of the returned user identity information.

The OpenID Connect provider authenticates the user through its authorization endpoint, and authenticates the client through its token endpoint.

The user requests access to a protected resource of the relying party through a user agent.
The relying party sends a user authentication request by redirecting the user agent to the OpenID Connect provider.
The OpenID Connect provider verifies whether the user has a valid session. Otherwise, the OpenID Connect provider prompts for user login and authenticates the user through the authorization endpoint.
Depending on the authorization grant type, the authorization endpoint of the identity provider can send an authentication response to the relying party that contains either:
- This authorization can then be passed in a request by a client, with an authorization code² that the relying party provides to a token endpoint in exchange for an ID token, an access token, or a refresh token.
- An ID token and access token.
  The ID token, or refresh token contains the user claims and signature that are used to establish the user session.
- A QR code, a user code, and URL.
- Implicit Flow. It performs authentication and authorization directly returning an ID token and access token to the client in its response.
Note: OpenID Connect provider Implicit flow does not support the token endpoint.

¹ These claims are statements about the user, which can be trusted if the consumer of the token can verify its signature. They are intended to supply the client application with consented user details such as email and name.

² an intermediate credential, which encodes the authorization.