In single sign-on implementation, protocol docking between systems is a very important link. Generally, standard protocols involved include CAS, OAuth, OpenID Connect and SAML. This paper will give an overview of the four mainstream SSO protocols and compare their similarities and differences.
One, authentication and authorization of the difference
Before introducing specific protocols, it is necessary to explain the difference between Authentication and Authorization.
-
Authentication is to confirm that the user is who he claims to be.
-
Authorization grants users the right to access specific resources based on their identities.
In other words, when a user logs in to the application system, the system needs to authenticate the user first, and then authorize the user based on the user’s identity. Authentication and authorization need to be used together to allow users to actually log in and use the application system.
Second, the CAS
Central Authentication Service (CAS) is a common SSO protocol based on B/S architecture. As with any OTHER SSO protocol, users only need to log in once and do not need to log in again to access other applications.
As the name implies, CAS is a service only for Authentication. Unlike OAuth/OIDC, CAS cannot be used as an Authorization protocol.
The CAS protocol includes CAS 1.0, CAS2.0, and CAS3.0. The authentication processes of the three versions are similar.
The CAS certification process consists of several participants:
-
Client: usually a user using a browser
-
CAS Client: a Web application that implements the CAS protocol
-
CAS Server: serves as the CAS Server for unified authentication
The certification process is roughly as follows:
-
The Client(end user) requests access to the Web application example in the browser.
-
The browser makes a GET request to visit the home page of the Example app www.example.com;
-
Run the example command to Redirect the user to the CAS server for authentication.
-
The user requests the CAS server.
-
The CAS server detects that the current user has not logged in to the CAS server, requiring the user to log in first.
-
The CAS server returns to the login page.
-
The user enters the user name and password (or other authentication methods) on the login interface.
-
The user submits the user name and password to the CAS server through POST.
-
The CAS authenticates the user. If the user name and password are correct, an SSO session is generated and the session ID is returned to the user’s browser through a Cookie (the user is logged in on the CAS server).
-
The CAS server also redirects users to the CAS Client and sends a Service Ticket at the same time.
-
After receiving the Service Ticket, the CAS Client Server requests the CAS Server to verify the Ticket.
-
The CAS Server returns the verification result to the CAS Client. The verification result includes whether the ticket is valid and whether the ticket contains information about the user.
-
At this point, the CAS Client obtains the identity of the current login user based on the Service Ticket, and the CAS Client is in login mode.
After the preceding process, both the CAS Server and CAS Client are in the login mode. When a user accesses another CAS Client 2, the user does not need to be authenticated again and steps 5, 6, 7, 8, and 9 are skipped to achieve SSO effect.
Note: CAS 1.0 is a very simple and crude protocol. In versions 2.0 and 3.0, the verification result of Service Ticket is in XML format, and a proxy mode is introduced (not discussed in detail in this article).
For details about the standard definition of CAS, see:
Apereo. Making. IO/cas / 6.2 x/p…
Author’s opinion:
1. CAS protocol is a simple single sign-on protocol. The protocol itself is lightweight and easy to implement, but it can solve a single scenario;
2. Clutter: CAS 3.0 also introduces samL-based Service Ticket verification.
3. The TRUST between the CAS Client and CAS Server is established through interface invocation without any encryption or signature mechanism to ensure further security.
4. The AUTHENTICATION mechanism of the CAS Client is insufficient.
5. There are not many applications implementing CAS in the market, and the author does not recommend this protocol.
Third, the 2.0
When we talk about OAuth, we usually refer to the OAuth 2.0 protocol, which is an Authorization protocol and not an Authentication protocol, although only Authorization is described in the OAuth 2 process. But in practice, Authorization without Authentication doesn’t make any sense.
**OAuth 2.0 addresses the main scenario of how third-party applications are authorized to access resource servers. ** The overall process participant consists of several components:
-
Resource Owner: Indicates the Resource Owner, usually a terminal user
-
Resource Server: Resource provider
-
Authorization Server: indicates the Authorization Server
-
Client: the application that requests service access
The abstract authorization process is roughly as follows:
Assume an online music service, zhangsan wants to play online music through some audio and video player software, but before playing music, the audio and video software must pass YuFu (IDaaS) authentication and authorization, get Zhangsan’s consent before accessing online music.
In this scenario, Zhangsan is the Resource Owner, online music service is the Resource Server, Client is an audio and video player software, and YuFu is the Authorization Server.
-
The audio and video software initiates an authorization request to Zhangsan, requesting Zhangsan to agree to access the online music service.
-
According to different authorization modes, Zhangsan agrees the authorization and returns a “authorization” to the audio and video service.
-
With zhangsan authorization, the audio and video service requests YuFu to issue an access_token for accessing online music.
-
After verifying the validity of audio and video services, YuFu issues access_token.
-
The audio and video service carries access_token, representing Zhangsan requests access to online music.
-
After verifying the Access_Token, the online music service provides the music service. The player starts playing music.
The above is an abstract authorization process, but in the concrete implementation, there will be several variations in the first three steps, namely different authorization modes. Common authorization modes include:
-
Authorization Code Grant: the most commonly used and secure Authorization Code Grant mode.
-
Implicit Grant: suitable for SPA applications, no longer recommended and replaced by PKCE schema;
-
Resource Owner Password Credentials Grant: Expose the user name and Password to the Client.
-
Client Credential Grant: The entire process has no concept of a user and applies to server -> server invocation scenarios.
It can be found that in the whole process, audio and video players do not need to know Zhangsan’s password, but only need to get Zhangsan’s Authorization to access online music, and the Authorization is responsible for by the Authorization Server.
The Authorization Code mode will not be discussed in this paper. Please refer to the detailed definition of the protocol document:
Tools.ietf.org/html/rfc674…
Compared with CAS, OAuth2.0’s different authorization mode can solve more scenarios, and is more secure and popular. Moreover, PKCE mode can realize single sign-on on mobile terminals, which is not available in other SSO protocols (PKCE mode reference: Tools.ietf.org/html/rfc763…
Four, OpenID Connect
OpenID Connect (OIDC for short) is a protocol extended based on OAuth2.0. In addition to OAuth2.0 Authorization scenarios, but also additional definition of Authentication scenarios, it can be said that OIDC protocol is the most popular protocol today.
Compared to OAuth2, OIDC introduces concepts related to userinfo such as ID_token:
-
The whole OAuth2 protocol only defines access_token and refresh_token, but these two tokens only protect Resource Server, without the identity information of Resource Owner.
-
OIDC introduces the concept of ID_token, using this special token to indicate that this is the ID of the Resource Owner:
-
Standardised id_token format: known as JWT;
-
Id_token Content: Standard Claims
- Reference: openid.net/specs/openi…
-
-
OIDC introduces an Endpoint on how to get detailed userInfo;
-
OIDC defines a Discovery interface similar to SAML Metadata, commonly known as the well-known interface:
- Reference: openid.net/specs/openi…
The login authorization process of OIDC protocol is basically similar to OAuth2.0, and the participants of the whole process are also similar, but with a different term:
-
OpenID Provider: OP for short, which is responsible for authentication and authorization
-
Adopt RP, OAuth 2.0 Client
It can be said that OIDC protocol is the most mainstream SSO standard protocol, and friendly to developers, relatively simple to implement.
For detailed definition of protocol standards, see:
Openid.net/specs/openi…
Fifth, SAML 2.0
The SAML protocol, called Security Assertion Markup Language, is an XML-based standard protocol. The SAML standard defines how Identity providers and Service providers exchange user Identity information through encryption and signature to establish mutual trust.
SAML is a very old Authentication protocol that was popular in the early enterprise applications of B/S architecture.
The SAML protocol is quite large and defines many optional details (that is, it is not mandatory). However, this is a double-edged sword, which is exactly the drawback of SAML protocol. As implementor, it has to take care of these optional details at the same time, which poses a great challenge for developers.
Technically, the SAML protocol is xmL-based and uses signatures and encryption to exchange user identity information in the form of Assertion. This is similar to the ID_Token in THE OIDC protocol (signed/encrypted ID_Token is used to exchange user identity).
The participants of the SAML process are Service Provider (SP) and Identity Provider (IDP), and the entire process includes the following scenarios:
-
SP Initiated: Initiated by the service provider
-
IDP Initiated: The identity server initiates an initiative
Here is the general certification process:
-
End User requests access to SP: www.example.com from the browser.
-
www.example.com If the user does not log in, it initiates SAML AuthnRequest request to IDP, and the user browser jumps to IDP page.
-
If a user is not logged in, the IDP redirects the user to the IDP login page and requests the user to authenticate the user
-
A user needs to verify the user name and password for identity authentication on the login page.
-
IDP verifies user identity. If successful, it sends the verification result containing user identity information to SP in the form of SAML Reponse signature/encryption.
-
After getting the user’s identity information, SP performs signature verification/decryption and gets the plaintext user’s identity information. At this time, SP is in the login state and can provide services to the user.
It can be seen that in the whole process, IDP issues user identities and SP trusts user identities issued by IDP. The trust relationship between SP and IDP needs to be established in advance. That is, SP and IDP need to configure information of both parties to each other in advance to establish mutual trust through certificate trust.
For the standard definition of the SAML protocol, see:
Docs.oasis-open.org/security/sa…
Vi. Simple comparison of each agreement
The main SSO protocols described above are essentially the same. They are all based on central trust. Service providers and identity providers exchange user information through mutual trust.
Finally, a simple comparison table is used to summarize the main points of this paper:
Click on the official IDaaS website to learn more about single sign-on, identity and access management
reading
IDaaS Technology Analysis (1) Single sign-on Token authentication
Balancing Token security and user experience
After SSO is complete, how can ACCOUNTS be automatically synchronized between systems?
