What is an Authorization Server for?

• Authorize user and applications to access Resource (API) with standard protocols (Oauth2.x)
• Strongly authenticate users and applications
• Deliver access token to apps to access Resource on behalf of users

What does a Resource (API) need from an Authorization Server?

• Security but it has to be easy (not its core job) so it relies on access tokens
• Data returned from the Authorization Server if you have valid access tokens

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.

The goal of this presentation here is to mitigate the following OWASP threats:

1. Broken (User) Object Level Authorization
2. Broken User Authentication
3. Broken Function level Authorization

Authorization Server can control access & easily apply additional security feature such as Multi-Factor Auth, Breached Password Detection or Device Security.

APIs and developers are happy as it saves time and reduces risk when building, maintaining, and securing APIs, just through access token validation.

But it raises several questions:

• What Oauth grant flow shall I use?
• JWT, JWE, JWS, what is all that?
• What if I need a Machine 2 Machine Token?
• What if I need Certificate-Bond Access Tokens (RFC 8705)?

Choosing the right Oauth Grant Type is key so that your client applications get access tokens securely. Access token rights can be validated in three different ways:

• with the JWT middleware included in your framework
• with 3^rd party libraries actively maintained and well documented
• by manually implementing a checking process:
  • retrieve and parse JSON Web Key,
  • decode the access token,
  • verify the signature,
  • verify the claim.

This issue applies to Single Page Applications & Long-lived sessions. Access tokens are short-lived. When they expire EUX (Enterprise User Experience) is impacted (redirect + auth if required). Instead of extending Access Tokens Lifetime, it is preferable to use Long-Lived Refresh tokens, that are made for that purpose.

But how to securely store Refresh Token in a public client application like SPA? The solution is to use Rotation (RFC 6819) that allows to expire a token and revoke it at each use, and send a new one along the Access Token. The threat is reduced and is a good compromise between UX and Security.

We are often in a situation where several API management platforms are chained between a consumer and the target APIs. The challenge then is to keep the user context through the different steps of the chain.

A consumer’s application can call an API with a first ClientID, ClientSecret to get the Access Token AB. On the second step APIB will use another set of ClientID, Client Secret to get the Access Token BC.

Say the end user is called John Doe.

The API using AccessToken AB will carry a sub-field like john.doe@example.com.

Where the API using AccessToken BC will carry a sub-field like api-b-client-id. We then have lost the user context. The problem is solved by using the Token Exchange Grant Type.

By default, APIs fully trust Authorization Server to authenticate and authorize user and client/applications. But for regulated environment, APIs may need more than trust.

For authorization servers, it can involve:

• Sharing how it authenticated user identity: password or multi-factor auth, or …
• Sharing last authentication time
• Sharing device context, ex: BYOD or Managed by company

For APIs (or API Gateway) it will provide:

• Higher Level of Assurance against takeover and frauds
• More dynamic control at API level
• Context to adapt response, e.g.:
  • Do not return sensitive documents if user devices are not managed (e.g Bring Your Own Device)
  • Return error code requesting a stronger authentication (stronger Level of Assurance)

As an example, PSD2 (Payment Service Directive 2) and financial requirements require to implement new standards with Oauth2 to secure access to API and Resource.

• (RFC 8705) Oauth2.0 Mutual-YTLS Client Authentication and Certificate Bound Access Token
• Securely authenticate interaction form Apps with Private Key JWT
• JAR/JARM – JWT – secured authorization request/response
• CIBA – Client-Initiated Backchannel Authentication
• DPoP – Demonstrated Proof-of-Possession of the Application Layer

”Scopes only come into play in delegation scenarios, and always limit what an app can do on behalf of a user” says Vittorio Bertocci  Principal Architect at Auth0, an Okta product unit.

Authorization Servers manage access limitations through scopes whereas fine-grained authorizations (permissions) are usually left to the responsibility of the back-end server.

This table shows the role and responsibilities in the API access processing.

In-line Authorization can be managed with different approaches:

• Role-Based Access Control (RBAC): permissions are assigned to users based on their role in a system
• Attribute-Based Access Control (ABAC): permissions are granted based on a set of attributes on a user or resource
• Relationship based Access Control: allows to express rules based on relations that users have with objects and those objects have with other objects.

There are different ways of implementing Fine-Grained Authorization (FGA). One of them is OpenFGA, an open source solution to Fine-Grained Authorization that applies the concept of ReBAC. It was created by the Auth0 FGA team and was inspired by Zanzibar. It was designed for reliability and low latency at a high scale.

To summarize, the best practices related to Authorization Servers and APIs are:

• Don’t overuse OAuth Scope, they are not permissions! Use an authorization service instead, like OpenFGA
• Don’t forget Refresh Tokens when building SPA Apps in front of your Backend APIs
• Be careful which Oauth Grant Type you choose, as it impacts security
• A happy relationship between S.S and API always include API Gateways
• Don’t forget about Token Exchange if you run into a Human 2 Machine 2 Machine situation
• Be super careful how you validate access tokens with 3^rd party library SDK

Source :

This article has been written after the presentation made at API days Paris 2022 event by Vincent Steenhoute – Senior Solutions Engineer – Okta

OIDC and Oauth basics

Choosing an OAuth 2.0 flow

2-legged OAuth protocol

3-legged OAuth protocol