Overview#

OAuth Scope Example shows an Example

What is the Problem?#

Currently many organizations have a history of various Access Control Models that have been used. When they used mainframes, RACF centrally controlled most application access and most applicaitons were on the mainframe.

As time went on distributed applications were deployed often each with their own Access Control Models.

As enterprises move toward an API Economy and enterprise data is shared between applicaitons via Representational State Transfer (REST) methods and given the current Cybersecurity environment, we find our existing Access Control Models lacking in the ability to:

• Be widely distributed amongst several applicaitons and utilize central Authentication and Authorization methods
• Perform Federation with third-party APIs
• Expose our APIs safely to our Business Partners.
• Manage scalability of our Application Resources
• Meet the current Cybersecurity Threats

What is done now?#

In a typical enterprise environment we would have a pipeline similar to:
Request --> API-Gateway --> Routing --> Application Logic --> Data Store

Often, the Application Logic or even the Data Store, determines the Authorization for the Application or API. The problem with this is we have a dependency in our Application (and/or Data Store) for a particular authentication method. As there are many Authentication Methods whenever we decide to change our Authentication Method, we also must change our Application.

If our Objective is to

• Expose our APIs safely to our Business Partners
• Manage scalability of our Application Resources
• Reduce (or eliminate) dependencies on our Application

Let us break down the problem and look at what is needed to determine Authorization.

For Access Control the API needs to know?#

• Who is the Authenticated user)? - provided by (subject)
  • OAuth 2.0 does not know - OAuth 2.0 NOT an Authentication protocol. (delegates Authentication to another Service).
• Which Application? (Mobile Device or J2EE or hopefully identified by client_id)
• What operations is Authorized to be performed? (provided by OAuth Scopes)

In OAuth 2.0/OpenID Connect#

• subject - who or Identity Token
• auth_time - When
• acr - Authentication Method (Authentication Context Class Reference) the user logged in (values from OpenID Connect)

If you design your Application and are using Google, you make assumptions about the values in the Access Token and Identity Token that may not work when you need to also add Facebook.

OAuth 2.0 + Authentication gives us the tools we need. (ie OpenID Connect)#

• subject - is an Identifier from Issuer for the Authenticated Entity, which is intended to be consumed by the OAuth Client, (comes from JWT values in OpenID Connect)
• aud - identifies the recipients that the Identity Token is intended for and each Entity intended to process the JWT MUST identify itself with a value in the audience claim. (comes from JWT values in OpenID Connect)
• scope - informs us what the the extent of access.
• auth_time- informs us when the Subject (User) performed the Authentication (comes from JWT values in OpenID Connect)
• acr - Authentication Method the user logged in (values from OpenID Connect)

OAuth Scopes#

Like permissions scopes specify the extent of the validated aud's access.

• Listed on the Consent UI (if UI provided)
• Consent UI is Not standardized

For an Example:#

In our Example the Subject is using a social Login even though they are a customer.

The following Implicit Scope is assigned (based on Authorization Policy) to the OAuth Client (we call the app ArticleReader) for all Successful Access Tokens returned:

• read_regular

The following OAuth Scopes that could be assigned to the Identity Token based on the Authenticated user:

• read_regular - for any successful Authentication
• read_premium - for any Customer
• read_write - for only employees

So the OAuth Client (ArticleReader) dances with the Authorization Server and we end up with The following OAuth Scopes:

• OAuth Client (ArticleReader) is always granted - read_regular OAuth Scope only - for any successful Authentication
• Subject (user) when using acr=social Login is granted - read_regular scope also.
• When the access is for read_premium and the acr=social Login, the Authorization Server looks for a associated "social Login" User in customer Data Store to determine if the user is also a Customer.
  • If the user is also a customer, then the read_premium OAuth Scope is returned within the Identity Token. (Even though it was not requested but as permitted by the specifications. Known as a Implicit Scopes)

In this scenario, then we end up with these scopes within the Identity Token

• read_regular - from client (ArticleReader) AND read_regular - any social Login
• read_premium - from Authorization Server looking up Resource Owner (user) = customer associated with social LoginID

Now, if we look at:
Request --> AccessProxy (Think PingAccess or maybe NGINX) --> Routing --> Application Logic --> Database

--> API-Gateway#

The API-Gateway could do the following:

• Access Token exist? (If not send them to get an access_token)
• Access Token valid? (Refused if not valid)
• Obtain and validate Identity Token (If invalid, refuse request)
• Identity Token contains one or more of the following scopes: (if NONE of them exist, we refuse the request)
  • read_regular
  • read_premium
  • read_write
• Abstracts the Authentication of the user from the Application and reduces to OAuth Scopes

--> Routing#

Routing, depending on the Architecture could be done with NGINX or IHS or Apache or any of the many Microservice frameworks

Assuming the request gets past the proxy, then the Routing (Think NGINX) now only needs to know:

• read_regular
• read_premium
• read_write

And based on these values, we can determine, perhaps, which route is required. Perhaps, the Router would know where to send each request based on the values of the scopes or aud values.

--> Application Logic#

By the time we get to the Application Logic, there should be little no need for Authentication and hopefully only fine grained Authorization logic embedded within the Application.

One of our many desires is to abstract the Authentication/Authorization logic away from application to a provide more centralized Access Controls and Audited

--> Data Store#

By the time we get to the Data Store, there should be little to no need for Authentication/Authorization logic embedded within the Data Store, perhaps only the Client_id and access permissions needed by the application.

What we are trying to do#

Remember what we are trying to do, is protect API access and optimize resources.

• From a security perspective, the closer they get to the data, the more serious the breach if it occurred.
• Likewise, from an optimization perspective, the closer they get to the data, the more resources we have expended.

Questions, Comments and Suggestions are always welcome.

More Information#

There might be more information for this subject on one of the following: ...nobody