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

by Paul Jones, Technical Manger

PathMaker Group

I’m your IAM program and I approve this message.

We have been bombarded by political ads of late, but there are lessons to be learned from these political campaigns. There are many reasons why Identity Access Management initiatives tend to fail. Treating your IAM program like it is running for office can give you a much better chance of success.

Vision & Beliefs

Create your program vision with guiderails for how to focus your program. What are the drivers for this program?  Where do your priorities lie between security efficiency, security effectiveness, and business enablement? Develop a high-level roadmap with the initial problems you want to solve.

Garner Support From Your Constituents

Toddler Campaigning

Meet with business leaders, architects, and organizations across your company to go over your IAM program road map and get feedback from them. Doing this will expose your program to new perspectives and will highlight opportunities which are mutually beneficial.  You will get visibility of the project and gets the business involved. Ask them how they want to be communicated with on the project status to keep them informed and involved.

Campaign Promises

With the new insights you have gained into the various business units needs, create some program KPIs and metrics. Exploit the pain points of the stakeholders to show value beyond your security directives. Here are some examples of metrics:

• Account and Access Provisioning time and resource cost:
  • Number of requests which were auto – provisioned vs manual provisioning tasks or service request tickets
  • Time comparing average manual task completion vs automated tasks
  • Number of resource hours spent involved in manual provisioning vs automated
• Delays on zero-day access:
  • Days after hire until birthright access is automatically granted vs manually requested and granted
• Costly and difficult application integrations
  • Number of systems integrated
  • Number of days average to onboard application
• Audit certifications process being tedious and expensive
  • Number of resource hours spent on administration of certifications
  • Average length of time to complete reviews
  • If access is revoked how long does it take for access to be removed on average
• Attestation Risk
  • Time to have access removed & accounts disabled for departures and scheduled terminations
  • Time to have access removed & accounts disabled for an immediate / unplanned termination
• Inherited access
  • Access & Accounts removed as part of a mover lifecycle event
• Orphan Accounts
  • Number of human accounts with no owner
  • Number of Service account with no owner
• Dormant accounts
  • Number of accounts which haven’t been used in a reasonable period
  • Number of accounts disabled / deleted from non-use policy process

Congrats! Armed with your vision, roadmap, and metrics, you won your election bid. Now go on your re-election campaign tour. Like listening to the polls, continually measure and get the impact of the program. Communicate your successes. Become your own marketing department.  Go to town halls, tech talks, team meetings or wherever you can talk about status of the projects and what is up next.

You have my vote!

Personalization is key to delivering engaging experiences but recent high-profile privacy abuses have made customers wary of how companies are using their personal information. They are increasingly reluctant to provide their data and increasingly worried about what’s being shared without their knowledge. These attitudes are reflected in the diverse geographic, industry and corporate privacy regulations that you need to take seriously.

Follow these four steps to prove yourself a trustworthy partner to your customers and protect yourself from the penalties of regulatory violations.

CREATE A UNIFIED VIEW OF YOUR CUSTOMERS.

The first step toward protecting the privacy of customer data is to have it all in one place. This includes basic information such as name and email address, sensitive information such as credit card numbers, unstructured data like purchase history, as well as critical consent permissions. Migrating or synchronizing all of this into one secure customer profile gives you customer insights that enable consistent crosschannel personalization, and it makes it much easier to protect and control all of your customers’ critical data.

COLLECT AND ENFORCE CUSTOMER CONSENT.

Many regulations, such as CCPA and GDPR, have directives that require you to collect consent, with hefty fines for violations. That means collecting and storing attributes that indicate which applications customers have agreed to share their data with, particularly external partner apps. Develop user-friendly interfaces to allow customers to see who has access to their data and manage which attributes they’ve consented to share. Providing this type of insight and control—and faithfully enforcing it, not just collecting it—will reassure them that you’re being a good steward of their data.

ENFORCE FINE-GRAINED DATA ACCESS GOVERNANCE.

Beyond saying either “yes” or “no” to an application when it requests access to a customer profile, you also need to control access to specific attributes. For example, a thirdparty marketing service may need API access to customer names, email addresses and opt-in preferences, but not transaction history. Customers may also want to restrict sensitive attributes from being shared with certain partner apps. Fine-grained data governance will ensure that you can enforce customers’ consent decisions.

CREATE CENTRALIZED POLICIES.

Meeting privacy regulations is nearly impossible when you’re trying to enforce those rules on an app-by-app basis, especially when the regulatory environment is in a constant state of flux. Centralized policies allow you to apply the same data access governance rules to all applications, so you can more easily stay up to date with the latest regulations (and demands from your customers). Application teams can request data the same way they always have, but only receive data and attributes that are compliant with regulations and customer consent decisions.