Looking through the OpenID Connect and OAuth specs, it seems that OpenID connect is all about identity and OAuth is about delegated access (though it seems to be specifically API access).
If OAuth is meant for API access, what is the recommended approach for managing client (e.g. a web portal) access?
Is this the job of the application itself (maybe via some backchannel request) or something that we can put onto an access token?
Hi @jpreese
Usually how you manage the client access is completely dependent on your needs.
For the company I work for, the dashboard is completely behind a login (so no pages have public/guest access). The way we manage access is simply to check if we have a valid access_token stored client-side, if so let them in, if not redirect them to the login page.
In terms of managing access depending on permissions this is also completely up to you as well. There are many methods, one of them is to have a roles claim in the access_token which your client can use to show/hide UI (remembering that ultimately your backend must validate their access as well) depending on the user’s roles.
Hope this helps!
It’s an interesting approach. Though if access token’s are meant purely for the client and do not dictacte what a given user can or cannot do, I was more leaning towards it being the responsibility of the client to make the call whether or not the auth’d user should be there or not.
In your case, the user would authenticate to your portal (client), and once the portal received and validated the idtoken, it could then make a call to a central auth and see if that user has access to that client.
Just to clarify, id_token is meant purely for the client side and access_token is what is passed to the API.
In our system we make an API call from the client to retrieve the user’s permissions after the client has validated that it has a valid set of JWTs.
Yep! I just understood your first message as:
If the user is not allowed to access the dashboard at all, don’t even grant an access token for that user. Then on your client you could just check if the access token exists or not. In your case there wouldnt even be an API call.
Did I understand that right?
Yes that’s correct!
That check can also be used for guest areas as well, so if no access_token is available the user is deemed to be a guest and only guest UI will be shown (and the API will reject any request to non-guest endpoints).
Ok that all makes sense. For one last piece of clarity, your Idp/IAM solution must be aware of the users (obviously) and the clients that they are allowed to access?
So somewhere in or before your /token endpoint, you’re making that check before creating an access token.
Regardless you’ll send them to the dashboard client, but if they were granted an access token is a different story.
For our use case, we have an Auth0 rule that ensures the user exists in our database (so creates the user if the user doesn’t exist) that way we don’t have to worry about missing users and such.
We also don’t have restrictions on which client they can access (from the Auth0 side). If they load up a dashboard they don’t have access to the access_token is still issued by Auth0 but the API rejects calls to any endpoints.
This may or may not be acceptable for your system, it really depends on your business requirements.