[Openid-specs-ab] About ID Tokens being access tokens
nov matake
nov at matake.jp
Mon Aug 29 23:37:00 UTC 2011
Your proposal gives id_token as a bearer token, so it sounds good for my library.
I think people wanted JWT format not to make check session call REQUIRED though.
On 2011/08/30, at 4:41, Andreas Åkre Solberg wrote:
>
> On 29. aug.2011, at 18:05, John Bradley wrote:
>
>> On the last call it was decided that the check session endpoint would NOT take the id_token as the access token.
>> You, Andreas, and perhaps Breno seem to think the id_token should be treated as the access token for the check session endpoint.
>
> I would say it depends.
>
> Right now,
> * the 'id_token' is not issued as a normal access token,
> * it cannot be associated with a token_type; instead it is defined to always be used identical to a 'bearer' token.
> * the 'id_token' has a 'deeper meaning' than a transparent handle, that makes the server endpoint want to access it.
>
> In the previous emails I've suggested to change all the three points above. Given, that we will not change the above I would say that I support to pass the token as a POST parameter (or similar) and not describe it as an access token, in order to reduce confusion, and for making it easier to access on the server.
>
>> Mov seems to have reasons that won't work with the OAuth lib he is using.
>
> In the proposal I've described in the recent emails; if the check session service was a 'Standard OAuth protected endpoint', and the token was transparent; the server would not need to access the token itself, instead if would verify through the OAuth Server API that the request was verified with a OAuth token in the correct scope.
>
> If we are talking about a 'more local' check session endpoint, and the implicit flow; then the JS client would not be able to send the Authorization header; and it would send it as a query string parameter instead; something that is allowed in the Oauth Bearer Token spec [1]; then the local server would be able to access the access token, and pass it on to the remote check endpoint service acting as an OAuth client.
>
> How does that sound, Mov?
>
> [1]: http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
More information about the Openid-specs-ab
mailing list