There are largely 2 frameworks of any IAM solution that allow users to access services and use them.
Authentication, where the user proves he is the true user accessing the application by passing their credentials to IdP and having them validated by the IdP.
Authorization is the permissions a user has that allows them to perform different actions in your application.
Users are typically issued access tokens, and any permissions not defined in the access token cannot be performed. The IdP, knowing the validity of the user after successful authentication, will issue OIDC tokens to the user which has an access token that defines permissions a user has in the application which details what tasks/actions they are able to perform.
We will cover how you can make best use of different scenarios of implementing access tokens using claims/scopes and audience.
Let’s Set It Up
Consider you have a service mesh which runs multiple services for your application. Following are the services you host which will be used by your application:
And following are the scopes you have defined for each for the user to perform actions through the application with these services you host:
Scenario 1: One Token for All
In the very first scenario we will see how you can simply have one single token with all the scopes required to access all the services through the application. It is as follows:
The user accesses the application:
- User logging in for the very first time, audience requested in the request along with required scopes for the audience, scopes are openid (required), offline_access (refresh token), read: payment, write: payment, read: cart, write: cart, read: products, write: products, read: orders, write: orders. The authentication flow type here is authorization code.
- The IdP gives the application an authorization code, this is because the authentication flow or the response_type is set to code in the request made in A.
- Using the authorization code issued in B, the application now makes a call to the IdP’s token endpoint to get tokens in exchange of the authorization code.
- In exchange of the authorization code, the IdP issues access_token, refresh_token and id_token to the application.
The token is always an encrypted string, but the decrypted access token will look like as follows:
- The information we are interested here is the audience, if you check the audience issued in the access token is same as the one requested in A during the initial login.
- Also, if we check the scopes, we have all the scopes in the access token which were requested when the token request was initiated in A.
- The scopes are; openid (required), offline_access (refresh token), read: payment, write: payment, read: cart, write: cart, read: products, write: products, read: orders, write: orders.
- This means the user has logged in and has this access token, has all the permissions possible to access various services hosted for the application.
- Thus, we have one token which has all the permissions for user which can be performed in the application user is logged into.
Advantage
- Simple for applications. They only need to fetch and use a single access token.
- APIs don’t need to be configured to accept multiple audiences. All APIs would accept the same audience.
- Fewer APIs to create/manage/deploy.
Dis-advantage
- No ability to fine tune permissions per application, all apps working with same pool of permissions
- Smaller pool of permissions, 1000 max across all domain APIs.
- A leaked access token has a large blast radius as it’s good for all APIs that accept that audience.
- If you need to restrict which APIs an application can call you would have to do it with additional custom logic you build. Would requires extra logic in the API checking scopes, permissions or Authorizing Party (app that requested the token) to allow/disallow calls by that app.
- No ability to tweak token settings lifespan, refresh token allowed, consent, permissions vs scope per app.
- Mingled permissions. Applications may receive tokens with permissions they do not require.
- An API could use the token it received to call any other service that falls under that audience.
Scenario 2: Breaking down the Audience for each API
In this scenario the application fetches one access token for each API they must access. Let us say we are vulnerable in scenario 1 where in we are giving away all the scopes for the application, so if the access token is leaked it is a concerning situation. Now we rather breakdown our Audience based on the 2 separate APIs which the application will be using.
- Audience 1: https://applicationAPIgeneral.com/
This audience will be used on and issued on the very first-time user is logging in. This audience will be valid for the API used by the application which has following scopes:
If you’d notice we do not have payment scopes on the first login of the user. In this way when the user is logging in for the very first time, they can access Cart, Products, Orders but not any payment related services. If the user has to access payment services, the application will have to make another call to get a new access token for payment with audience intended for payment API. Note: this will be a simple redirect by the application to the IdP to get a new access token, user does not have to login again as the user already has a valid on-going session.
- Audience 2: https://applicationAPIpayment.com/
This audience as the name suggests is only intended for the payment API which will be accessed by the application and has only following 2 scopes required for payment:
Let us look at the flow:
The user accesses the application for the first time:
- User logging in for the very first time, audience requested in the request along with required scopes for the audience, scopes are openid (required), offline_access (refresh token), read: cart, write: cart, read: products, write: products, read: orders, write: orders. The authentication flow type here is authorization code. Note the audience here is: https://applicationAPIgeneral.com/
- The IdP gives the application an authorization code, this is because the authentication flow or the response_type is set to code in the request made in A.
- Using the authorization code issued in B, the application now makes a call to the IdP’s token endpoint to get tokens in exchange of the authorization code.
- In exchange of the authorization code, the IdP issues access_token, refresh_token and id_token to the application.
Following is the access token issued by the application which has scopes and audience for the API which allows user to access everything the application but the payment service:
- Now after spending some time, the user now wants to access payment services to do payments, when user tried to access payment service, it will not be denied by the application, but rather application will make a call to the IdP to get a new access token for the user with payment audience https://applicationAPIpayment.com/ which can be used by payment API of the application with payment scopes.
The second token issued by the IdP for payments is as follows:
Advantage:
- Tokens are specifically for a single API, so a leaked token has a smaller blast radius.
- No token will include permissions that don’t apply to the api it has as audience.
- Settings like expiration and whether refresh tokens are allowed can be configured per API.
- Services cannot use the token they received to call other services.
- You can further break down your application’s APIs and have application request an access token for each. Example in this case, you can have up to 4 access token calls made by your application one each for Orders Services API and Scopes, Cart Services API and Scopes, Products Services API and Scopes, Payment Services API and Scopes.
Disadvantage:
- Apps have to fetch tokens for each API Silent Authentication lets you do this without prompting the user for credentials and the SPA SDK helps with this process. Silent Authentication can be performed at 10 RPS per user session. Certain browsers including Safari have tracking prevention that can interfere with Silent Auth. In that case Rotating Refresh Tokens must be used and a full redirect would be needed to fetch each token.
- Each individual API must be created, managed and deployed.
Bottom line
- The scenario 2 always looks secured than scenario 1, but remember, you should also understand your requirements. If scenario 1 fits you better, simpler and does not leave you with vulnerability, you can always stick to 1.
- It is really important to understand your architecture and requirements in hand and not only considering amount of work will take for operations but also how your business is growing and how you will address new upcoming requirements with your growing business i.e. more applications, more services, more users, SSO, etc.
RAAH Technologies provides Identity and Access Management solutions that give your company the flexibility to grow, change, adapt and prosper. RAAH Technologies’ tailored services maximize existing resources, identify crucial gaps in IAM capabilities, and implement foundational IAM solutions that are future-proofed. We understand the complexities of Identity in all its forms and apply our expertise to deploy solutions across multi-faceted and diverse environments.
Download our FREE GUIDE: The Journey to Next Generation IAM or Get a Free IAM Assessment from RAAH Technologies.