Message, Standard - Why id_token not access_token?
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)
-
-
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.
-
sorry, I've commented as anonymous.
-
reporter -
assigned issue to
- changed status to open
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?
-
assigned issue to
-
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.
-
-
assigned issue to
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.
-
assigned issue to
-
-
assigned issue to
Also delete the sentence saying that the ID Token MUST NOT be used as an access token.
-
assigned issue to
-
re
#390change check id to Bearer token -
re
#390remove prohibition against using id_token as access token in Sec 2.1.1 -
re
#390change check_id ti Bearer -
- changed status to resolved
Fixes
#390change check id to Bearer token< -
re
#390Sec 5.3 fix verification rule to match bearer -
change sec 5.3 to match bearer for check_id re
#390 - Log in to comment
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.