OIDC in Action – An OpenID Connect Primer, Part 2 of 3

Developer Blog Comments
1

OIDC in Action – An OpenID Connect Primer, Part 2 of 3

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.

2

Oli

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”: “okta_oidc_fun@okta.com” whereas in ID Token the claim is “sub”: “00u2yulup4eWbOttd1t7”. Is there any correlation between these two “sub” claims?

3

Micah

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:


{
    “active”: true,
    “amr”: [
        “pwd”
    ],
    “at_hash”: “liTu18PkaNVObRctS09bOA”,
    “aud”: “0oa2yrbf35Vcbom491t7”,
    “auth_time”: 1529984429,
    “email”: “okta_oidc_fun@okta.com”,
    “exp”: 1529988041,
    “full_name”: “Okta OIDC Fun”,
    “iat”: 1529984441,
    “idp”: “00o1zyyqo9bpRehCw1t7”,
    “iss”: “https://micah.okta.com/oauth2/aus2yrcz7aMrmDAKZ1t7”,
    “jti”: “ID.Aryj4IVG5vffdqGz_n7GXbDFbAipvdFQ1sBcrfjOBI0”,
    “name”: “Okta OIDC Fun”,
    “nonce”: “af948789-ead2-4cfa-a89b-379f95c5cc52”,
    “preferred_username”: “okta_oidc_fun@okta.com”,
    “sub”: “00u2yulup4eWbOttd1t7”,
    “token_type”: “Bearer”,
    “username”: “okta_oidc_fun@okta.com”
}

4

dearvivekkumar

Hi Micah,

Thanks a lot for composing this series of articles. It is very helpful :slight_smile:

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?

5

Micah

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.

6

Sylvain Verneau

Hello,
thank you so much for this articles.

I had the same experience than Oli
In the access token payload, sub is an email address

https://uploads.disquscdn.c…

But in the response of userinfo endpoint, there is what seems an alphanumeric id.

https://uploads.disquscdn.c…

What sub is ?

7

Micah

The sub in the /userinfo response is Okta’s id for that user