What’s in a Token? – An OpenID Connect Primer, Part 3 of 3
This blog series is a primer on OIDC. In this final post, we’ll look at what’s encoded into the various types of tokens and how to control their contents.
Eduardo Andrade
Great series of articles!
Thanks for writing it!
Micah
Glad you dug it! Thanks.
Aninda Bhunia
Great articles, thank you. If we want to de-couple the auth provider (in this case Okta) and the resource server (lets say this is an API gateway), if a user needs to authenticate and then access an API protected by the API gateway, is it appropriate to design the approach in this way -
1. User authenticates to auth provider and the client is issued an OIDC ID Token.
2. When client tries to access a protected API, the ID token (issued by Okta/auth provider) is presented to the API Gateway (resource server).
3. Resource server validates the ID token, determines the user identifier (in the sub) and high level scopes from the ID token.
4. Resource server issues an Access token that represents the scopes/authorizations available to this user and sends back to client.
5. Client presents this access token to API Gateway to get access to the authorized APIs.
If this approach is acceptable, then what needs to be configured for the API gateway to ‘trust’ the ID token issued from Okta.
If this approach is not acceptable, can you please help identify the right approach? My thought was that the API gateway is best suited to determine the authorizations for a particular identity but Okta is best suited to authenticate the user (i.e. i dont want to necessarily maintain all the authorizations possible for an identity in Okta).
Thanks
Micah
The Authorization Server is responsible for issuing tokens. So, it wouldn’t work to have the Resource Server issue an access token. Typically, at authentication time, both an id token and an access token (and potentially a refresh token) would be issued by the Authorization Server. The API Gateway (via its own session management, for instance) would be able to use the access token to interact with a backend API on a Resource Server on behalf of the user. You might be interested in another post I made on OAuth & OIDC using the open source Kong API Gateway: https://developer.okta.com/…
Aninda Bhunia
Thanks for the clarification and i apologize as should have been more clear -
In this scenario, one could argue that the API Gateway can in fact act as the Oauth2 Authorization server for the purpose of the Oauth2 access token that will be presented to the resource server (the API being accessed) by the client (the web site trying to access the API). Oauth2 requires that the user be authenticated before the Oauth2 authorization server issues the access token, but the spec is open to what is accepted as ‘being authenticated’. So what i am asking is that in this case, can the Okta issued OIDC ID token be presented by the user agent (lets say browser) to the API Gateway as proof of authenticated identity and then based on the scopes requested by the client (and consented by the user), issue the access token to the client?
The core question is if an OIDC ID token (issued by Okta after successful authentication) can be presented by the user agent to the API Gateway (that is acting like the Authorization server to the enterprise APIs) as proof of authenticated identity, after which the API Gateway issues the Access token to the client for subsequent access to enterprise APIs.
Micah
I’m not sure I follow. Are you saying that the API Gateway would issue an access token and would therefore maintain its own public and private key pair? This seems like reinventing the wheel to me. The ID Token does provide proof of identity, but I am unclear as to why you wouldn’t just get an access token at the same time you got the ID token if you need it for authorization purposes to a backend resource server.
Govind Bisht
Hi Micah,
Thanks for the detailed description. However I have a scenario I would like to discuss with you. I have one SPA which requests authorization token from Okta. This token is then passed to my webapi which validates it with Okta. Now I have a scenario where I want user to have access to Apis based on there groups/roles. So will it be a right way if my application flow works like this:
1) SPA asks for id_token from Okta.
2) SPA sends this id_token to WebAPI to prove that request is authenticated.
3) WebAPI asks for authorization code from Okta using the provided id_token.
4) WebAPI sends this authorization code to SPA, which in turn use this with every request made to webapi.
5) WebAPI will verify this authorization code everytime with Okta before allowing a user to access a resource.
I’m confused if this will be the right way or not?
Any help will be appreciated
Micah
Hi Govind:
The scenario you laid out is more complex than necessary. You can include the groups list from Okta in the access token.
On your Resource Server, after the token is verified, you can extract the groups claim and then your API can decide if the user is authorized to do whatever they’re trying to do.
This behavior can be configured in the Okta Admin Console.
Hope this helps!
Tobias Bacalzo
Great article! Can you please recommend an approach for SSO across multiple web apps using OIDC? Which tokens, if any, should be shared between applications?
francis
Definitely one of the best articles on the subject.
Micah
Thanks! Much appreciated.
John Doe
These are great posts! Claims can be added to both ID Token and Access Token, but just wondering if there are any pros and cons adding to one or another. Would be dependent on the use case?
Micah
Yes, dependent on use case. The ID Token is intended to be used as proof of authentication and is kind of a “throw away”. That is, you validate it, extract the information, and then put the user in an authenticated state with whatever sort of system you’re using. The access token is meant to be presented as a bearer token representing the user. In addition to validating the digital signature, you can extract scopes and claims, which will drive authorization decisions.
Micah
Thanks! For SSO concerns, you would use the ID Token. For backend APIs (like, multiple micro-services), you would use the Access Token for authorization.
Tobias Bacalzo
Thank you so much for responding. Do you have any site or standards doc that you could refer me to that could go into more of the details of such an implementation?
Tobias Bacalzo
Thanks. I’ll check it out.
HExit
Hi Micah, I just want to say thank you, this is the best OIDC articles I read.
Deepak Pathak
At then end of this brilliant tutorial and helping me tremendously to understand what OIDC is all about and it’s little nuts and bolts, I want to thank you from my heart…
Big Hug and Love from India <3