There are usually multiple systems in an enterprise. Assuming that users need to enter their own account/password to log in before entering each system, they can still receive each account/password when the number of systems is small. If the number of systems is large, users will not be able to receive them. Single sign-on solves this problem well.

The principle of single sign-on is that users can access multiple systems only by logging in once.

There are many protocols available for single sign-on. The following will briefly introduce four common single sign-on protocols: CAS, OAuth2, OpenID and SAML.

CAS protocol is a token-based protocol. It is used for single sign-on or logout of Web applications, and the content of the protocol is to standardize a set of URIs for login/logout. See:/blog/2014/05/oauth _ 2 _ 0.html for details of the agreement.

This paper focuses on the single sign-on process using Oauth2:

The latest version of OpenID is OpenID Connect, which is the third generation technology of OpenID. OpenID Connect allows all types of clients, including browser-based and local mobile applications.

OpenID is used to authenticate the end user, and OAuth2 is used to authorize the resources of the client when the user's identity is known to be legal. OpenID Conect = OpenID + OAuth2 .

Openid connection is based on OAuth protocol. In OAuth2, there is a special scope "openid" to identify OpenID requests, and an idtoken field is added to the return body of OAuth2 to identify users.

The single sign-on process using OpenID Connect is the same as Oauth2.

At present, many domestic applications (browsers or mobile phones) support third-party authentication such as WeChat and Weibo, for example. This third-party authentication can be achieved through OpenID Connect.

Please note that general business applications will support the use of third-party authentication.

SAML interacts through XML and is based on HTTP.

Let's briefly introduce the basic terms involved in SAML protocol.

IdP: Identity provider refers to the service that provides identity management. Common IDP owned by enterprises include AD FS, Shibboleth, etc. And cloudidps includes Azure AD, Okta, OneLogin, etc.

SP: Service provider refers to an application that provides users with specific services by using the identity management function of IdP. SP will consume the user information provided by IdP. In some non-SAML identity systems (such as OIDC), service providers, also known as relying parties, are the relying parties of IdP.

SAML: Security Assertion Markup Language is a standard protocol for enterprise-level user authentication. It is one of the technical ways to realize the communication between SP and IdP. It is the de facto standard of enterprise identity alliance (SAML 2.0).

SAML Assertion: short for assertion. SAML assertion is the core element used to describe authentication request and authentication response in SAML protocol. For example, a user's specific attributes are contained in the assertion of the authentication response.

Trust: Trust refers to the mutual trust mechanism established between SP and IdP, which is usually realized by public key and private key. SP obtains the identity federation metadata of IdP in a credible way, which contains the public key corresponding to the private key used by IdP to sign SAML assertion, and SP can use the public key to verify the integrity of assertion.

Refer to the case of single sign-on in Alibaba Cloud:/doc/document _ detail/69969.html.

Reference link: /p/5d535eee0a9b

Which single sign-on method to choose needs to weigh the pros and cons.