Message, Standard - Why id_token not access_token?

Issue #390 resolved
Nat Sakimura created an issue

Nov, what was the reason for not having id_token as not an access_token to check_id endpoint?

I think it was something like that id_token can be big and blows up your framework.

If there is no problem, it would be easier to explain it as access_token to bearer endpoint.

Comments (13)

  1. Michael Jones

    The consensus on the working group call was that the ID Token should be an access token to the Check ID Endpoint and that the messages should be standard OAuth Bearer messages.

  2. Former user Account Deleted

    My Ruby library is designed to extract (and validate expiry etc) in middleware layer. In that layer, acting in different way based on the requested endpoint is a tricky way. Of course, I can let my library users hardcode id_token supported endpoints in the middleware layer, or check token includes double "." etc., though.

  3. Nat Sakimura reporter

    So, let me understand it clearly.

    In OAuth implementations, there can be multiple protected resources which requires different access tokens. All the access tokens may be completely opaque.

    How does the library handle these?

  4. Nov Matake

    My library get an access token from header/body/query and confirm it's not expired/invalidated. So that application don't have to check token validity and just check its scope.

    However, it seems many providers tend to use different format of access tokens with same token type. So I may have to re-think my library's structure.

  5. Michael Jones

    Sounds like Nov has a workaround at least. Therefore, I'd recommend that we decide on Monday to go with the working group consensus from the last call and change the Check ID endpoint to be an actual OAuth protected resource.

  6. Log in to comment