This article is intended to provide a brief overview of OAuth 2.0, SAML 2.0 and OpenID Connect as well as the pitfalls of confusing authentication and authorization.

OAuth2, OpenID Connect and SAML are the most commonly used protocols which delegate the tasks of authentication or authorization to an entity separate from the service or resource being accessed. SAML 2.0, OAuth 2.0 and OpenID Connect will be referred to as SAML, OAuth2 and OpenID respectively for the sake of brevity. Let us start by looking at each solution’s use case.

OAuth 2.0

OAuth2, standing for Open Authorization, provides mechanisms which allow a user (resource owner in OAuth2 terminology) to authorize a service (client) to access the user’s data on another server (resource server). This is accomplished by retrieving appropriate credentials, e.g. an access token, from an authorization server, which the resource server trusts. The client then uses this credential to access the data from the resource server. The resource server can be designed to use different methods to verify the authenticity of the credential, a common one being verifying an embedded cryptographic signature.

A common example used to illustrate this dynamic is a user authorizing a printer device to access their photos in the Google Cloud. The OAuth2 specification does define a few processes to accomplish this authorization transfer to accommodate a variety of setups. One of the simplest is the following: The printer wants to access the user’s photos in the Google cloud, so it sends the user to google with a link that contains information about who wants access, what access is wanted and where to send the credential to, such as the following: https://oauth2.google.com/?scope=photos&client_id=bobs_printer&redirect_uri=https://192.168.1.1/. Google makes the user authenticate when visiting the link and asks the user if it wants to grant the client bobs_printer access to its photos. If the user allows the access, the user is sent back to the website of his local printer with a URL containing the credential, such as https://192.168.1.66/?access_token=SG93IGRvZXMgTW9zZXMgbWFrZSB0ZWE/IEhlIGJyZXdzLiBoZWhlaGVo. The printer can then use this token in a request to the google photos server to access the user’s photos.

SAML 2.0

SAML, standing for Security Assertion Markup Language, allows a service (service provider in SAML terminology) to delegate the authentication and authorization of a user wanting to access it to a central authentication server (identity provider, or IDP). Like OAuth2, SAML supports different flows to accomplish its goals, which are called bindings in SAML-World. While it should not be compared to OAuth2, a SAML binding can follow the same basic redirects described in the OAuth2 example. There are however different model assumptions and trust relationships and the issued token is intended for the service provider. The IDP will supply the service provider a signed XML document containing assertions on the user’s identity and his authorizations.

The three different SAML bindings examined here are artifact, POST, and redirect binding.

Redirect and POST binding follow a redirect-scheme as described in the OAuth2 example, with the difference between the two being the location in which protocol data is passed. POST binding transmits SAML messages in the request body of HTTP POST request while redirect binding uses URL parameters.

While Redirect and POST binding give the user’s browser a signed XML message to authenticate with at the service provider, artifact binding only supplies an opaque token, the SAML artifact. When receiving the artifact from the user, the service provider contacts the IDP directly to retrieve the signed XML message associated with the artifact. The XML message contains the actual authentication and authorization assertions for the user. This approach reduces the exposed attack surface significantly by eliminating an attacker’s possibility to attack the complex XML parsing and validation. Since the service provider and IDP need to communicate directly, this binding type often requires heavier integration.

OpenID Connect

OpenID accomplishes the same basic tasks as SAML. While it ditches XML for more web friendly JSON, the big difference functionality-wise is OpenID’s support for discovering and interacting with, potentially arbitrary, authentication servers (OpenID providers). This discovery and interoperability set it apart from SAML, where IDP’s and Service Providers need to be integrated with each other and also usually have strong trust relationships. OpenID builds on top of OAuth2 to provide an additional identity layer, allowing users to be authenticated. Thus, OpenID follows the same basic procedures when delegating user authentication as described in the OAuth2 example. The primary extension that OpenID makes to OAuth2 is the ID token, a data structure containing claims about the authentication of an end-user.

Authentication vs. Authorization

Having a strong understanding what authentication and authorization each provide is valuable to avoid, often subtle, mistakes in delegation implementations. OAuth2 is conceived as an authorization protocol, while OpenID Connect and SAML also provide authentication. Authentication answers the question, who an entity is. Authorization on the other hand says what an entity is allowed to do. To give an example, a password is needed to access a database. Anyone who was supplied the password is authorized to access the database. From the database’s point of view, everyone who comes along with the password is authorized, however it cannot make any meaningful assertions on which of all the authorized individuals is accessing it. A secure authentication provides the means to make assertions on an entity’s identity with a high degree of confidence.

Oauth2 allows an entity to authorize a service to access the entity’s data on another server. If this authorization protocol is used to either authenticate users or fetch and use data with authenticating properties in any business logic, an application opens itself up to vulnerability. First, let us explore why it’s difficult to provide authentication with the standard OAuth2 paradigm.

An example could be an online forum which lets users authenticate by providing the forum access to their social media profile, from which the forum server fetches their identity information. The forum identifies users by name and birth date. From a purely technical standpoint, this is a perfectly fine use of OAuth2: The user authorizes the forum to fetch its data from the social media site. A malicious user, let us name him Jefferson, would like to remove forum posts which do not coincide with his world views. Jefferson can create a new social media profile using the same name and age as the poster of the post he wants removed. Upon authenticating by granting the forum access to this new social media profile, the forum sees that the retrieved name and age match and gives Jefferson access to delete the other person’s posts and to further impersonate him.

Despite OAuth being used soundly on a technical level, the vulnerability obviously arises from the user data not being uniquely identifying, the forum developers think, so they now also fetch the user UUID from the social media platform, which uniquely identifies a social media user. Other Questions the developers may not have asked are if different social media sites users can authenticate with implement UUID’s in a manner where they can be controlled or manipulated by users. Also, is the forum willing to let their security be compromised by arbitrary business logic decisions of another company? Such questions need to be addressed in order to have any confidence in the security of the authentication.

Meanwhile Jefferson, who incidentally owns a video sharing site which also uses the social media platform to retrieve user data, notices his disliked forum poster also has an account on his site. This means Jefferson can look up the access token to the user’s social media his video sharing site was provided and inject it into the authentication flow when accessing the forum. Jefferson is once again authenticated with the forum as his disliked forum poster. From the forum’s point of view, it received a valid access token with which it could fetch user data from the social media site. It assumes that because the valid access token was presented, the entity presenting it must in fact be the user it is fetching data for. This is now obviously not the case and illustrates possible pitfalls of mixing authentication and authorization or assuming one from the other. This situation where the forum cannot know who it is being accessed by based on the access token is essentially the same as with the database password example. However, in this case, it is masked by the fact that an access token is only issued when the user authenticates itself.

OAuth2 can provide some additional facilities which allow both the authorization server and the resource server to make some limited assumptions as to how the authorization process can be conducted. These were omitted for the simplicity of the example. At its core, OAuth2 is nonetheless an authorization protocol.

OpenID is built on top of OAuth2 to also allow secure authentication. One facility it provides to accomplish this is the ID token which contains claims on the identity of a user. The ID token is supplied by the server authenticating the user. This is the main difference between OpenID and OAuth2. While in OAuth2, the authorization server only supplies an access token for the resource server, the additional ID token authenticating the user is supplied in OpenID. Since the basic structure of an ID Token is specified, a “relying party” (the service requesting a user be authenticated from an OpenID provider) can rely on these.

Conclusion

While the underlying concepts of the authentication or authorization delegation in all three solutions are sound, room for error increases with their customizability for a variety of different setups with often subtle differences in trust relationships and model assumptions. With all three solutions, the devil often lies in the details. When implementing a solution, all model assumptions need to be carefully analyzed to discover present security vulnerabilities.

About the Author

Ahmet Hrnjadovic is working in cybersecurity since 2017. There he is focused in topics like Linux, secure development and web application security testing. (ORCID 0000-0003-1320-8655)