The OAuth 2.0 Authorization Triangle

/in /by

By Thomas Johnson

Solutions Architect at PathMaker Group

 

 

Have you ever heard of the Bermuda Triangle ?

It’s a place in the Northern Atlantic where ships and planes have mysteriously been lost at sea. We won’t try and solve those mysteries today, but will hopefully make the OAuth 2.0 Authorization a little bit less of a mystery with this article. You can think of the OAuth 2.0 Authorization as a triangular relationship between the three major actors in the OAuth 2.0 framework. Thinking of it like a triangle really helps in illustrating the problems being solved and how to best apply the concepts with OAuth 2.0 industry standard best practices. Note this article addresses authorization concepts, not the underlying authentication.

High Level Concepts

 

There are three major actors involved with Authorization in the OAuth 2.0 industry standard, each having a three-way relationship with the other two actors. These are the high-level concepts involved between the three actors. The overlying concept here is least privilege. Take a look at the following illustration.

 

(1) The OAuth Client is a security component coupled with the web application that users will access. The web application will typically need to reach out to other resource or back-end servers to get content that goes in the web pages, but to get access to the servers it will need to do the following:

  • Request an access token from the Authorization Server for the particular Resource Server that it needs to access in order to get the protected web content
  • Present the access token that was obtained through the OAuth Client to the Resource Server to show proper authorization for access to the protected web content

(2) The Resource Server is the API server or back-end service supplying the web content that will go on the web pages in the web application

  • It parses the access token presented by the web application to verify that the OAuth client was authorized to access the resource
  • It validates that the access token used by the web application was indeed issued to the OAuth client and has been authorized by the Authorization Server

(3) The Authorization Server is the actor that issues the access token to the OAuth Client and provides for validation of the access token from a Resource Server

  • It checks that the OAuth client is allowed to obtain a token for a resource on the resource server and that the scope or permission requested by the OAuth Client is allowed
  • It may optionally provide claims in the access token to allow for further restriction on which resources can be accessed by the web application
  • It also provides for validating the access token from a Resource Server. Was the token really issued by this Authorization Server and has it not been tampered with?  In some cases it can let the Resource Server know if the token is still valid and has not been revoked

OAuth 2.0 Standards

So how do these actors perform these functions using OAuth 2.0 best practices ? The RFC 6749 specifies an OAuth2.0 framework for applying these concepts to web applications and Authorization Server implementations.

OAuth Client

(1) When the OAuth Client requests a token for a specific resource server it should specify an audience parameter that indicates the intended Resource Server to the Authorization Server. The idea behind the audience parameter is to restrict which clients can obtain an access token for a particular Resource Server (least privilege model). Not just any client should have access to the Resource Server.

(2) The OAuth Client must specify the permission requested through a scope parameter. In some cases the resource owner may need to authorize the permission requested and in other cases it may be implied.

Resource Server

(1) When the Resource Server parses the access token it should check:

  • The audience value in the access token to verify that the token presented by the web application via the OAuth Client is intended for itself and not an access token issued by the Authorization Server for something else
  • The claims in the access token to determine if the resource being called in the API is allowed, for example groups claims

(2) The Resource Server needs to validate the access token was issued by the Authorization Server and it should validate the token is still valid by:

  • Calling the token introspection endpoint of the Authorization Server with the Access Token presented by the web application
  • Validating the signature of the access token using the keyset of the Authorization Server well-known endpoint to ensure the token indeed came from the Authorization Server and was not tampered with, it should also make sure the token is still valid by looking at the time stamp

Authorization Server

The Authorization Server is the actor responsible for minting (issuing the token) for the OAuth Client, on behalf of the Resource Server and in some cases approval from the Resource Owner.

(1) It should check the following in the token request:

  • It should check that the OAuth Client is allowed (allowed list) to obtain an access token destined for a particular Resource Server by looking at the audience parameter requested in the token request
  • It should check the scope (permission) requested by the OAuth Client to see if it is allowed for that particular resource server

(2) RFC 9068 provides a JSON web token profile which makes it possible for an Authorization Server implementation that mints tokens that have claims allowing for providing group information in the access token further restricting access to protected resources

(3) It should check the following if the token is being validated by introspection:

  • The token was indeed issued by itself and not a different Authorization Server
  • The token has not been tampered with
  • The token is still valid, active, and not revoked