Closed shuppert closed 8 years ago
The spec says access tokens are opaque to the client. You shouldn't be doing that.
Thanks Brock. I have a client application that will have access to multiple environments but likely not all of them (e.g. 10 different REST services). I was hoping that I could include claims for each authorized environment in the access token and have the client application parse the token so it knows which environments the authenticated user can access. Do you have any advice on a better way to implement this?
Yes, the providers should support OIDC and also return an id_token -- that's a token designed to convey identity info to the app.
You lost me. My understanding is that custom claims can only be added to the access token not the Id token. I also have an Id token that tells the application who logged in but it doesn't provide any information on what authorizations they have.
OAuth2 does not provide any info to the client, only an opaque access_token for using at a web api.
OIDC adds the concept of an id_token that is meant for the client app to know the identity and claims of the user.
The token service you're using could put any claims into either token. What token service are you using?
As for application authorization logic, that's not part of either spec.
I'm using IdentityServer3. I read something yesterday (I don't remember where) that custom claims could be added to the access token but not the Id token. Is that bad information?
Correct, bad info :)
Is there support for parsing the access token and reading the claims in the calling application with OIDC Token Manager? I was able to use the property name to get data from the profile (e.g. mgr.profile["email"]) but I haven't been able to do the same with the access token (e.g. mgr.access_token["idp"]).
-Scott