SAML vs. OAUTH

SAML and OAUTH are technical standards for authorizing users. These standards are used by Web Application developers, security professionals, and system administrators who are looking to improve their identity management service and enhance methods that clients can access resources with a set of credentials. In cases where access to an application from a portal is needed, there is a need for a centralized identity source or Enterprise Single Sign On. In such cases, SAML is preferable. In cases where temporary access to resources such as accounts or files is needed, OAUTH is considered the better choice. In mobile use cases, OAUTH is mostly used. Both SAML (Security Assertion and Markup Language) and OAUTH (Open Authorization) are used for web Single Sign On, providing the option for single sign-on for multiple web applications.

SAML

SAML is used to allow web applications’ SSO providers to transfer and move credentials between the Identity Provider (IDP), which holds the credentials, and the Service Provider (SP), which is the resource in need of those credentials. SAML is a standard authorization and authentication protocol language that is mostly used to perform federation and identity management, along with Single Sign On management. In SAML, XML metadata documents are used as a token for submission of the client’s identity. The authentication and authorization process of SAML is as follows:

1. The user requests to log into the service via the browser.
2. The service informs the browser that it is authenticating to a specific Identity Provider (IdP) registered with the service.
3. The browser relays the authentication request to the registered Identity Providers for login and authentication.
4. Upon successful credential/authentication check, the IdP generates an XML-based assertion document verifying the user’s identity and relays this to the browser.
5. The browser relays the assertion to the Service Provider.
6. The Service Provider (SP) accepts the assertion for entry and allows the user access to the service by logging them in.

Now, let us look at a real-life example. Suppose a user clicks the Login option on the image-sharing service on the website abc.com. To authenticate the user, an encrypted SAML authentication request is made by abc.com. The request will be sent from the website directly to the authorization server (IdP). Here, the Service Provider will redirect the user to the IdP for authorization. The IdP will verify the received SAML authentication request, and if the request turns out valid, it will present the user with a login form to enter the credentials. After the user enters the credentials, the IdP will generate a SAML assertion or SAML token containing the user’s data and identity and will send it to the Service Provider. The Service Provider (SP) verifies the SAML assertion and extracts the data and identity of the user, assigns the correct permissions to the user, and logs the user into the service.

Web Application developers can use SAML plugins to ensure that the app and resource both follow the needed Single Sign On practices. This will make for a better user login experience and more effective security practices that leverage a common identity strategy. With SAML in place, only users with the correct identity and assertion token can access the resource.

OAUTH

OAUTH is used when there is a need to pass authorization from one service to another service without sharing the actual credentials, like the password and username. Using OAUTH, users can sign in on a single service, access the resources of other services, and perform actions on the service. OAUTH is the best method used to pass authorization from a Single Sign On platform to another service or platform, or between any two web applications. The OAUTH workflow is as follows:

1. The user clicks the Login button of a resource sharing service.
2. The resource server shows the user an authorization grant and redirects the user to the authorization server.
3. The user requests an access token from the authorization server using the authorization grant code.
4. If the code is valid after logging into the authorization server, the user will get an access token that can be used to retrieve or access a protected resource from the resource server.
5. On receiving a request for a protected resource with an access grant token, the validity of the access token is checked by the resource server with the help of the authorization server.
6. If the token is valid and passes all the checks, the protected resource is granted by the resource server.

One common use of OAUTH is allowing a web application to access a social media platform or other online account. Google user accounts can be used with many consumer applications for several different reasons, such as blogging, online gaming, logging in with social media accounts, and reading articles on news websites. In these cases, OAUTH works in the background, so that these external entities can be linked and can access the necessary data.

OAUTH is a necessity, as there must be a way to send authorization info between different applications without sharing or exposing user credentials. OAUTH is also used in businesses. For example, suppose a user needs to access a company’s Single Sign On system with their username and password. The SSO gives it access to all the needed resources by passing OAUTH authorization tokens to these apps or resources.

Conclusion

OAUTH and SAML are both very important from a web application developer’s or system administrator’s point of view, while both of them are very different tools with different functions. OAUTH is the protocol for access authorization, while SAML is a secondary location that analyses the input and provides authorization to the user.