Multiple access tokens for the same client_id but different scopes

[namithakrshn]

I am working on an Angular application that needs to access different backend APIs(with different scopes). Hence this angular application (with just one client_id) needs to be able to request and store multiple access tokens in the sessionStorage.
I see that when I request access tokens for the same client_id but different scopes, the token gets overwritten in the storage since the storage key is the client_id.
Is there a workaround for this?

[damienbod]

Could you not just request one access token with the scopes for all the APIs? Doesn't make sense to have multiple tokens in the browser.

Greetings Damien

[inpicksys]

@damienbod Could you please share your plan about upcoming release -> when it approximately will be? Thanks.

[namithakrshn]

@damienbod There are certain Authorization servers such as Azure AD B2C which only issues an access token for a single audience value.
For example: A resource API1 exposes two scopes namely api1.read and api1.write
Another resource API2 exposes two scopes namely api2.read and api2.write
Azure AD B2C does not let me request for scopes api1.read and api2.read with a single access token. B2C only supports single audience value in an access token and it requires me to make separate calls for every resource that I need to access.
For such implementations of OAuth authorization servers, we will need to store a token for every resource that the Angular app accesses.
Any thoughts?

[damienbod]

@namithakrshn I plan to add this for the version 11 release, or just after.

[damienbod]

@namithakrshn . Just released 11.1.0 which supports Azure B2C. I plan to support this feature next. My idea is that using the forceRefreshSession, you can request new scopes as required. You can only have one access token at anytime, unless you save this yourself. Would this work for you?

[namithakrshn]

@damienbod For Azure B2C use cases, I think it would benefit to be able to store multiple access tokens at a time and have the means to renew those access tokens when required. Storing the tokens by myself takes away the advantage of seamless renewal obtained using the library.

In my use case, we can have a group of APIs all associated with the same coarse-grained scope. So if i access one API from that group and then discard that token, then I will have to end up requesting for the same scoped access token again when accessing another API from that same group.

[damienbod]

@namithakrshn Would it not be better to put an API in between, the API is only for the SPA and all the different security flows etc are implemented securely in the trusted backend. Then you reduce the attack surface. The API can use the OBO flows to access the other APIs, flows and so on.

[damienbod]

Implemented, will be release in V12