This blog series is a primer on OIDC. In this post, we’ll dive into the mechanics of OIDC and see the various flows in action.
Very interesting blog.
At this point there’s one fact that i don’t understand:
When I use the introspection endpoint I get claim “sub”: “firstname.lastname@example.org” whereas in ID Token the claim is “sub”: “00u2yulup4eWbOttd1t7”. Is there any correlation between these two “sub” claims?
Thanks! I am unable to reproduce your experience. I see the Okta ID in the sub claim of the ID Token. And, when I hit the /introspect endpoint, I see the sub in the same way - the Okta ID.
Here’s the output I get from the ID Token from the introspect endpoint:
“full_name”: “Okta OIDC Fun”,
“name”: “Okta OIDC Fun”,
Thanks a lot for composing this series of articles. It is very helpful
I have few concern regarding the IMPLICIT Flow as below
What are the general strategies for saving the ACCESS_TOKEN? Because I think passing the ID_TOKEN and ACCESS_TOKEN in each API call is too much payload, beside the security concern related with ACCESS_TOKEN.
I am thinking of using OIDC implicit flow and preparing a plan for it. Can you please provide me some pointer about the better way of managing the ACCESS_TOKEN?
Hey there! Thanks for the comment.
The access token should not generally be very large. Using it for authorization against a backend api is the appropriate use of the access token.
If you’re using the Okta SignIn Widget, it has a tokenManager built into it that uses (protected) local storage to store the tokens.
Generally speaking, if you’re talking about a browser, you have two primary choices for the access token: cookie or local storage. If you go the cookie route, you’d want to use httponly and secure flags to keep it safe.
thank you so much for this articles.
I had the same experience than Oli
In the access token payload, sub is an email address
But in the response of userinfo endpoint, there is what seems an alphanumeric id.
What sub is ?
The sub in the /userinfo response is Okta’s id for that user