Quick Introduction of the protagonists: Authorization Servers & API
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
OpenID and Oauth 2.0 – the dreamland and the challenge to implement it
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:
- Broken (User) Object Level Authorization
- Broken User Authentication
- 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)?
Challenge #1 – Having a good access token conversation
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 3rd 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.
Challenge #2 – Best practices when using Single Page Applications (SPA)
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.
Challenge #3 – Machine 2 Machine 2 Machine /…
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 firstname.lastname@example.org.
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.
Challenge “4 – Trust or Zero trust
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
Challenge “5 – Access Token scopes are not permissions
”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.
Access limitation (scope)
|Fine-Grained Authorization (permissions)|
|The process of verifying someone’s identity||The process of controlling user access to an app and app access to an API on behalf of the user||The process of limiting what an app can do on behalf of a user||The process of evaluating if a user can perform a certain action on a specific resource|
|In-line authorization (database) or 3rd party service|
|Identity & Access Management Solution||OAuth Authorization Server||OAuth Authorization Server||Authorization Service|
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.
Conclusion & Take aways
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 3rd party library SDK
This article has been written after the presentation made at API days Paris 2022 event by Vincent Steenhoute – Senior Solutions Engineer – Okta