A User logs in to my SPA using OIDC. My SPA communicates with its own backend REST API, and I would like to protect access to that API with an OAuth Access Token. The role of the User that logs in will determine which API endpoints they are allowed to access, and in what capacity. The backend API is not the User's data. It is the SPA's own API that has nothing to do with user data. An Admin
user will be able to create and read resources via the API, and a Standard
user will just be able to read resources via the API. I'm using Okta as my Identity Provider/Auth Server.
My SPA needs to know the user's assigned role before requesting an appropriately scoped Access Token for the backend API. So, I'm thinking that I need to log in the User, inspect the user's role in the ID token, and then somehow make an additional request to the Authorization Server with the proper scopes included (either just read
, or read write
). But I'm a little confused because I'm not sure what flow I would use to make this additional request (or even if I need to!). I mean, I already get an Access Token bundled with the ID token when the User logs in, but it's not really scoped for the backend API.
I hope that is clear. What is the appropriate action I should take here?
Thanks
Here is a revised answer, since it is a year after the original one, and I guess both of our understandings have moved on a little.
SCOPES
The scopes represent the types of data a client application is allowed to access. If different users have rights to different areas of data, the application scopes do not change.
USE A CLAIM, NOT A SCOPE
When you want dynamic authorization based on the user identity, the answer is almost always a custom claim, which is just another field in the token. So ideally you want your apps to receive tokens that contain this type of data:
{
role: 'admin'
}
WHERE TO ISSUE THE CLAIM
HOW TO ISSUE THE CLAIM VALUE
This can be done in a couple of different ways:
USER ID TRANSLATION
In some cases, this can involve translating from the Okta User Id (the subject claim) to your API's own User Id.
IF YOU CAN'T ISSUE A CUSTOM CLAIM
Then you can look up the role in your custom API when it first receives the token, then use the value as a custom claim in your API's code, as in my Authorization Write Up. The value of the claim could then be returned to the UI via an API call.