[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