Access Management: Securing APIs using OAuth2.0

If you’ve followed my first Identity & Access management article lately, you are no doubt familiar with the three major identity protocols in use today: SAML, OpenID Connect & OAuth2.0. In this second part of the series, we’ll be going more in depth into the OAuth2.0 protocol and its crucial role in identity and access management security.

With APIs being used in mostly everything these days, it’s getting more and more common for an application to implement different APIs from different providers offering different functionalities. Let’s say you have a Single Page Application (SPA) that offers e-commerce services for a retail company. This particular SPA might be using a payment API, a shopping cart API, a coupon and voucher management API, product listing API, etc.

In this type of scenario, controlling who has access to what is very important from a security perspective and the ability to limit and control API access is very crucial; this eliminates lots of unsecured APIs risks such as brute force attacks and DDoS attacks.

That’s where OAuth2.0 comes in.

What is OAuth2.0 ?

What the heck is OAuth2?

OAuth is an authorization protocol that gives an API client limited access to user data. Using OAuth2.0, it is possible for the application to access the user’s data without the disclosure of the user’s credentials to the application. The API will grant access to the resource owner (user) only when it receives a valid token from the application.

This given ‘access’ is based on authentication flows called Authorization Flows or Grants which allow the user to share the protected content without sharing their credentials (explained later in the blog). Let’s start by defining the OAuth2.0 roles.

• Resource Owner: This is the user, the entity that can grant access to the protected resource.
• Client: Application requesting access to a resource server (Spotify looking to access your facebook contacts events to import them)
• Resource Server: Server hosting protected data (for example Google hosting your profile and contact information)
• Authorization Server: Server issuing access token to the client. This token will be used for the client to request the resource server.

OAuth2.0 is not an authentication protocol

OAuth2.0 Scopes & Claims

Before diving into the authorization grant types, let’s start by defining some key concepts and explaining what scopes and claims are in the OAuth2.0/OpenID Connect universe.

“Scopes only come into play in delegation scenarios, and always limit what an app can do on behalf of a user”

A scope is used to specify what privileges are being requested , it’s an indication by the client that it wants to access this particular resource; the server may allow or reject this.

Below are some scope examples :

Claims are basically specific information or attributes about the user. Wikipedia defines it as the following “A claim is a statement that one subject, such as a person or organization, makes about itself or another subject”. Here’s an example:

Many Profile claims are included in the example above. That’s because the request for the user’s info was made using a token that was obtained with the profile scope. In other words, a request is made that results in the issuance of a token. That token contains certain information based on the scopes specified in the original request.

OAuth2.0 Authorization Flows

OAuth2.0 supports many authorization flows (also called grant types), these flows are used to get an access token (+ a refresh token if needed) from an authorization server.

Access token are used to access the protected resources, they usually have a short lifetime, so in case of a security leak of the access token, the damage can be controlled. When the access token expires, developers can integrate refresh tokens which will transparently request new access tokens, hence not asking the users to enter his login credentials again.

OAuth2.0 provides different types of flows for API clients:

Resource Owner Password Credentials

Unless the client is highly trusted, this flow should not be used as the credentials are directly entered on the client application. Here’s the workflow:

1. The client asks the users to input his credentials.
2. The client application sends the login to the authorization along with it’s own identification. The authorization servers check the sent information and returns an access token (+ refresh token if needed).
3. User accesses the resources via the access token.

Authorization Code

The authorization code flow is probably the most commonly used OAuth2.0 flow type. It is used by both native mobile apps and web apps. The main difference compared to other flows is that this flow requires the app to launch a browser to initiate the flow.

1. The application opens a browser to send the user to the authorisation server.
2. The user will be prompted to login either on the authorization server itself or by federating to a third party identity provider.
3. Credentials are sent to the authorization server.
4. If the authentication is successful, the authorization server will redirect the user back to the client application by providing an Authorization Code.
5. After that, the client application will make a request (containing the authorization code) to the authorization server to receive the access token. If the request is successful, the authorization server will respond with an access token and a refresh token.
6. The client application uses the access token to access the protected resource.

Authorization Code Flow with PKCE

The Authorization Code with PKCE (Proof Key for Code Exchange) is the most secure of all OAuth2.0 flow. It follows the same flow type as the Authorization code but adds randomly generated values called ‘Code Verifier’ and a ‘Code Challenge’ to the flow.

1. The Code verifier is random generated value during the beginning of the flow. The application then hashes the Code verifier and the result is the Code Challenge.
2. The application then kicks in the authorization code flow in the same fashion, except that the Code challenge is added in the query string for the request in the authorization server.
3. The authorization server stores the code challenge for later verification, and after authentication redirects to the app with an authentication code.
4. Just like the Authorization code flow, the app makes the request to exchange the code for the token, but here’s the twist, it sends the Code verifier instead! Now the authorization server hashes the Code Verifier and verifies it with the hashed value stores earlier. If these two hashes match, the authorization servers returns an access token.

Feel free to comment on this article, would gladly discuss any related matter down below.

Credits to Ratros Y. for the flow diagrams.