SSO is the abbreviation of single sign-on. There are two commonly used SSO protocols, namely SAML and OAuth2. This article will introduce the differences between the two protocols so that readers can have a deeper understanding of the two protocols.
The full name of SAML is Security Assertion Markup Language. It is a set of open standards based on XML format developed by OASIS and is used to exchange authentication between identity providers (IdP) and service providers (SP). and authorization data.
A very important application of SAML is Web-based single sign-on (SSO).
Three roles are defined in the SAML protocol, namely principal: the representative subject usually represents a human user. identity provider (IdP) identity provider and service provider (SP) service provider.
The role of the IdP is to perform identity authentication and pass the user's authentication information and authorization information to the service provider.
The function of SP is to verify user authentication information and authorize users to access specified resource information.
Next, let’s analyze how SAML works through a flow chart of using SAML for SSO authentication.
In the above figure, the User Agent is the web browser. Let's take a look at how the SAML protocol is handled when the user wants to request resources from the Service Provider.
The SP will perform corresponding security checks on the resource. If it is found that there is already a valid security context, the SP will skip steps 2-7 and go directly to step 8.
RelayState is a state information maintained by SP, mainly used to prevent CSRF attacks.
This SAMLRequest is encoded in Base64
For security reasons, SAMLRequest can also use the signature key provided by the SP. to sign.
After receiving this AuthnRequest, the IdP will perform security verification. If it is a legitimate AuthnRequest, the login interface will be displayed.
This form contains SAMLResponse information, and SAMLResponse contains user-related information.
The same SAMLResponse is also encoded using Base64
We can see that samlp:Response contains saml:Assertion information.
We can see that all the information exchange above is completed by the front-end browser, and there is no direct communication between SP and IdP.
The advantage of this way of exchanging information entirely by the front end is that the protocol flow is very simple, and all messages are simple GET or POST requests.
If you want to improve security, you can also use quote messages. In other words, what the IdP returns is not a direct SAML assertion, but a reference to a SAML assertion. After the SP receives this reference, it can query the real SAML assertion from the background, thereby improving security.
The SAML protocol was formulated in 2005. When the protocol was formulated, it was basically aimed at web applications, but web applications at that time were still relatively simple, let alone support for apps. .
SAML needs to transmit user information through HTTP Rect and HTTP POST protocols, and data is usually submitted in the format of HTML FORM. If the application is not a web application, for example, it is a mobile App application.
The startup link of this mobile APP application is my-photos://authenticate, but the mobile app may not be able to obtain the body content of the Http POST. They can only pass parameters through the URL.
This means that SAML cannot be used in mobile APPs.
Of course, if you want to work, you can, but it will require some modifications. For example, the POST message is parsed through a third-party application, and then the parsed SAMLRequest is passed to the APP in the form of URL parameters.
Another method is to use OAuth2.
Because Oauth2 was only produced in 2012. So there aren't that many usage restrictions.
We can use OAuth2 in different situations.
Let’s first take a look at the flow chart of authorization in OAuth2:
Generally speaking, there are 4 roles in OAuth2.
Resource owner: Represents the owner of the resource, which can be authorized by providing a username, password or other methods. Usually comes alone.
Resource server: represents the server that ultimately needs to access the resource. For example, the user information obtained after github authorization.
Client: A client used to replace the resource owner for interaction.
Authorization server: The server used for authorization can generate the corresponding Access Token.
The whole process is as follows:
The client initiates an authorization request to the resource owner, and the resource owner enters the corresponding authentication information and returns the authorization grant to the client.
The client then requests the authorization server to obtain the authorization grant and returns the access token.
The client can then use this access token to request the resource server, and finally obtain the restricted resources.
OAuth2 does not specify how Resource Server interacts with Authorization Server. There is also no regulation on the content and format of returned user information. These need to be decided by the implementer himself.
OAuth2 works in an HTTPS environment by default, so there is no agreed encryption method for information. We need to make it happen ourselves.
Finally, OAuth2 is an authorization protocol, not an authentication protocol. For this problem, we can actually consider using the OpenID Connect protocol. Because OpenID Connect is implemented based on OAuth2 and adds an authentication protocol.
OpenID Connect, referred to as OIDC, has become the universal standard for single sign-on and identity management on the Internet. It builds an identity layer on top of OAuth2 and is an identity authentication standard protocol based on the OAuth2 protocol.
OAuth2 actually only does authorization, while OpenID Connect adds authentication on top of authorization.
The advantages of OIDC are: simple JSON-based identity token (JWT) and fully compatible with OAuth2 protocol.
In the SAML protocol, the SAML token already contains user identity information, but in OAuth2, after getting the token, an additional verification of the token is required.
But on the other hand, OAuth2 requires another authentication, so the token can be invalidated on the Authorization Server side.
Anyone who has done SSO should have heard of CAS. The full name of CAS is Central Authentication Service, which is an enterprise-level open source SSO authentication framework.
CAS internally integrates CAS1,2,3, SAML1,2, OAuth2, OpenID and OpenID Connect protocols, which is very powerful. We will introduce the use of CAS in a later article.