The OAuth 2.0 Authorization Triangle

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

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!

Vote For IAM!

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!

Four Steps To Customer Data Privacy

 

 

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.

 

It’s Time to Change the Cybersecurity Metaphors We Use

Source: Pat Muoio, Wall Street Journal

 

There’s a lot to be learned from the words we use to describe things. Cybersecurity is a case in point.

The prevailing metaphor people use when they talk about cybersecurity is that of attack— of cyberwar and cybercrime. It’s understandable, but such language aims our solutions outward at the attacker, with tools focused on things like perimeter defense, threat assessment and analysis of attack surface. In short, we focus on the bad guys.

Contrast that with the notion that cybersecurity is all about keeping an organization’s systems healthy. Now our attention is turned to internal monitoring, avoiding risky behaviors, closing down vulnerabilities—the open wounds that let bad things take hold. We examine ourselves.

This isn’t a semantic issue. The focus on the perimeter—or how the bad guys are getting in this time—forces organizations to fight back on the outsider’s terms. They end up chasing after new tools to prevent the attack du jour, without thinking how those new tools might interact with the cyber defenses they already have in place. In short, organizations give up the home-field advantage that comes from having detailed knowledge of their own systems and data.

Consider phishing, where hackers try to entice people to click on bogus links in emails with the aim of stealing user credentials. The success of phishing gave birth to cyber tools that let users know if links are safe to click. Yet phishing is just one of many ways hackers steal credentials—they also do it via password guessing, keystroke logging, even stealing the sticky note on which a password is written. Deploying separate tools to protect against each of those attack methods isn’t practical. Two-factor authentication, however, makes stolen credentials useless regardless of how they are obtained. This is a solution that addresses the correct operation of a system, not the specific type of attack itself.

Regardless of how a breach occurs, there is a very limited set of actions hackers can take to execute an attack once they gain entry. These actions enable the hacker to become privileged users on the system and to steal, encrypt or corrupt data, or to execute commands that can cause the system to break down. Detecting and neutralizing these universal actions is easier and more efficient than trying to detect every which way those actions might be combined or every trick hackers might use to evade detection.

All of this makes a compelling argument for talking about cybersecurity in terms of health rather than attack. This change of rhetoric will get organizations thinking about systemic solutions based on their understanding of the systems they create and run. Now the bad guys don’t dictate the terms of engagement.  They can use whatever techniques they want to disguise their approach because the approach doesn’t matter. If organizations can stop hackers from executing, they don’t have to stop them from getting in.

One big benefit of this way of thinking is that organizations can achieve full protection with fewer solutions. They don’t need to constantly assess the threat environment; that activity becomes the purview of security researchers, not a task that needs to be done by every organization trying to secure a system. An attack by Russia is neutralized the same way as an attack by an amateur hacker because when it comes down to executing, they have the same set of actions available to them.

This may not be as glamorous or dramatic as the idea of engaging in a mind-to-mind “war” with hackers, but it is much more effective.

Digital Transformation: Customer Identity Access Management

The fourth of our Virtual Panel Series focuses on the role of CIAM in digital transformation. Our panel of experts will discuss key factors that affect this relationship and provide recommendations for ensuring an organization’s successful transformation using a flexible and extensible CIAM framework.

Access the recorded panel session here. 

Identity Governance: Aritificial Intelligence and Machine Learning

Identity governance is now a critical component of most organizations’ identity and access management strategies. It allows businesses to securely provide automated access to digital resources, while at the same time managing compliance risks.
Some of the key challenges when considering identity governance are around identifying and maintaining roles and policies that help simplify and control assignment of accesses, especially when you are talking of large enterprises with many disparate applications. By leveraging the concepts of artificial intelligence (AI) and machine learning(ML) these challenges can be significantly reduced.
The focus of the discussion will be around the value that AI and ML can bring to Identity Governance solutions and what we can expect from technology vendors that specialize in this space.

Safeguarding User Identities

Presented by PathMaker Group, Pontis Research, SecurIT and Okta.

Access Webinar Recording Here