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

Drive to Survive

/in , , /by

Excelling in the Identity Access Management Space

by Harold Black, Senior Solution Architect

 

Many are familiar with the popular television show Drive to Survive. For those who are not acquainted with the show, it is a behind the scenes look at the world of Formula One (F1) racing.

You may wonder what does F1 have to do with the Identity Access Management (“IAM”) space? There are many commonalities between the two, some more nuanced than others. The obvious parallels are:

1. They are in it for the long run. IAM is a program not a project. Formula One is a series with multiple races over the course of the year generating points toward a championship.

2. They require teamwork – an F1 requires drivers, engineers, pit crews and so on. A strong, mature identity team requires developers, analysts, and operations people. Each job has its own set of skills and lessons learned and must have the ability to work well with other groups within the larger team. Attempting to have anyone fill too many roles will lead to lower performance and static thinking.

3. They require Strategic and Tactical thinking. Any given F1 race weekend contains multiple mini events – practice rounds, qualifying rounds, and race day. Each phase lays a foundation for the next and consumes time and materials from a finite pool of resources. All of this is with the aim of contributing to the larger goal. A tactical decision that is solid in the moment can be catastrophic in the long run. Conversely a strategic decision that sounds good without the resources or support to make it a reality is a sure way to hit the wall. Sound familiar?

This brings us to less obvious similarities between F1 and IAM – the Drive to Survive. Every good team in any endeavor understands their success drivers.

 

 

F1 teams design their cars with success drivers in mind. Some teams are faster on the straight aways, others on the curves. Some focus on reliability and asset management to gain some points every race. Others win a big once or twice and seldom score the rest of the year. There is no wrong answer; it’s about the team’s personality and resources that establish their “success drivers.”

In the IAM world this means program business drivers. These drivers lay the foundation for what your program is all about and lead to the way you design your systems and processes, and prioritize your work. Without adherence to a driver focused program development, teams end up with an assortment of nice but disjointed features, a collection of unsupportable processes and conflicting priorities, which makes everyone unhappy.

What does a driver focused program management mean? In the Identity world, the primary drivers are Security, Compliance and Business Enablement. Each of these have variations and subsets but they boil down to one of the three. Each has arguments to support why they are number one.

• The business will say, “We should be the primary driver because we make the money”.
• Security will respond, “That may be true but we make sure we get to keep it”.
• Compliance will say, “We prevent regulatory fines and hits to stock prices”.

All three are correct and must be addressed in your program.

The way to a successful race is to identity your drivers, determine the value of each, spot the point of diminishing returns and establish a ranking system for each driver. When you have competing requests for your limited resources, a well understood prioritization tool allows you to focus your efforts and gives the customer a realistic view of the “finish line.” Attempting to make everyone happy at once leads to hitting a wall and losing a chance for a win.

So in conclusion, establish your drivers, start your engine, and enjoy the race to success!