OAuth 2.0 and OpenID Connect - App Security Mantra

OAuth 2.0 is very popular today and there is also a lot of confusion about OAuth 2.0 vs OpenID Connect. In this post we will understand what problem OAuth 2.0 solves and how it is different from OpenID Connect.

Lets start with revisiting some basic concepts and then develop our understanding about OAuth by trying to solve a specific problem.

Authentication vs Authorization

Authentication is the process of verifying identity. Here we validate the users are the ones they are claiming who they are. Typically user provides something they know like user name and password.

Authorization is process of verifying what someone is allowed to do. It is about the permissions and access control.

API Authorization Today

Let’s consider a scenario where we want to allow an application to access an API to send an email on user’s behalf. Now we will discuss different solutions from past and how we solve it today.

Credential Sharing

In the past we used to see this a lot, this was done using something called ‘Credential Sharing’.

User is asked to provide a username and a password so that application will login to the API on users behalf. No way for API to differentiate between a user and the client application (application impersonating user). So application can access any part of the API, potentially can delete an email or even change the password.

It will also then break other applications using the API since credentials become invalid. It becomes more problematic when applications needs to save these credentials and in case of SPA.

Cookies

Another solution to protect APIs. User redirected to API and enter credentials to get cookie. Restrict access by having user decide what functionality to allow.

Cookies have a problem called CSRF (Cross Site Request Forgery) . When user logs in and get the cookie, application can access api. However when user opens another tab and tries to access the same API, use is still authorized. It is true for any other application opened in browser, in a way we have given access to browser not just a single application.

Better Solution – OAuth 2.0

OAuth 2.0 is basically an authorization framework specifically built for HTTP APIs. It allows user to secured delegate scoped API access to an application. By scoped API, user defines exactly what part of API they want a particular application is able to access.

Once granted, application can then talk directly talk to the API making OAuth 2.0 a delegation protocol. There are mainly four players involved here –

Protected Resource (HTTP API)
Client (Requesting Application)
Resource Owner (User)
Authorization Server (OAuth Server)

Typical OAuth authorization request flow follows below sequence of events, it is easier to understand it from the next picture –

Client application makes authorization request to authorization server. This is done via browser so that resource owner physically redirected from client application to authorization server. Once user is in authorization server and authorization request is validated successfully, authorization server challenges the user to verify their identity.
Now user need to authenticate and consent about permissions. Notice that user credentials handling completely removed from client application.
User authentication can be done by any method we want, we can use multi factor authentication or can allow user to sign in using Google or Facebook credentials. It is actually outside of OAuth specification. Once authenticated, they need to consent authorization request where list of permissions (which client application is requesting) is present.
After consent, user is again redirected back to the client application. In this redirect, authorization grant is included. It is typically a physical representation of user’s authorization of client application to act on their behalf. Let’s consider this as a random value only authorization server understands.
Client application then makes a back channel request to authorization server (unknown to browser) . In this request it includes authorization grant and also some way of authentication itself as a valid client . If everything is correct, server sends response back with an access token. Only application that was given authorization grant can swap it for the access token.
This access token can be then used by client application to authorize a request to the protected resource. This is sent over using authorization header, scheme defined by authorization server. Typically bearer scheme is used and looks something like –

Authorization: Bearer <token>

When protected resource receives an access token, it has to be verified. Now it is again out of scope for OAuth 2.0 specification to define exact structure and validation procedure for this token. It can be structured like Json Web Token (JWT) or completely unstructured. It can be verified by within protected resource or could be sent to authorization server for validation.

This is one of the may possible OAuth flows and there are different scenarios.

OAuth 2.0 is an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.

There are some misunderstandings and confusions about OAuth 2.0.

We need to understand that OAuth is not for authentication. Access tokens do not represent an authenticated user, in fact there may not be an end user at all.

Access token’s intended audience is the protected resource and the client applications don’t even need to look inside the access token. Instead they should just request and pass in on to to protected resource. So there is no way for client to reliably verify the token and authorization server has no obligation to its clients regarding access token format or scheme.

Sometimes OAuth 2.0 is said to be too abstract as it does not define things such has how access token looks like, how to validate these tokens and anything about user authentication. So many people implemented these things on their own which differs from each other and adds to confusion.

By scoping itself as authorization protocol OAuth 2.0 solved the problem of delegating access and API access control. It also offered a simple solution to separate user credentials from third party client applications. In addition to this, user consent provides a transparent understanding of data access to the parties involved.

OpenID Connect

The OAuth 2.0 is for (delegated) authorization and not for authentication. It does not give client application any sort of indication about user and how they authenticated.

Sometimes we need authentication to start with and to identify the user. Many OAuth provider like Facebook tried to implement their own identity layer on top of OAuth. All of these providers had to add some protocol variations and had their own implementation problems. So to avoid all these variations, there came a need to form a formal protocol which became OpenID Connect.

OpenID Connect not only adds identity layer on the top of OAuth 2.0, but also formalizes some of the OAuth ambiguities by defining token types, standardizing cryptography and validation procedures. It is not change to OAuth, it only adds to it. By using OpenID Connect, your authorization server also acts as an identity provider.

Looking at the protocol, OpenID Connect provides descriptions for some additional features like session management and discovery document etc.

Now with OpenID Connect, we bring new protected resource into the system. It is API typically hosted within our identity provider called user-info endpoint. Access to this API is again scoped.

One more feature of OpenID Connect (OIDC) is Identity Token. Access tokens intended audience is the protected resource, ID token is intended for client application. When client receives the token it verifies the data within it and whether it is tampered or not. It is done using public key cryptography. Identity token is a Json Web Token (JWT) which contains the claims in its payload part and it has a verified signature.

OpenID Connect takes the OAuth 2.0 framework and adds an identity layer on top. It provides information about the user, as well as enables clients to establish login sessions.

Conclusion

OAuth 2.0 is a protocol designed for authorization i.e. granting access to protected resources (data, APIs etc.) from one application to another. OpenID Connect (OIDC) extends OAuth 2.0 by adding a thin layer of authentication on the top of OAuth 2.0.

Developers should note that comprehensive security can only be achieved by trust. In particular, the client implementation of OAuth 2.0 as well as the user agent play a large role in the overall level of security achieved in an OAuth 2.0 ecosystem, and any authorization/authentication provider is reliant on them to provide a secure environment.

Thank you for reading. Stay Safe, Stay Secure!