[Openid-specs-ab] About ID Tokens being access tokens
ve7jtb at ve7jtb.com
Sat Aug 27 02:38:17 UTC 2011
I currently have them as OAuth protected resources. On the last call people wanted the check session endpoint to take the Id_token as a parameter rather than as a access token. I think the argument is that the token is easier to access as a parameter. I think that is a potential problem with the OAuth lib.
Sent from my iPhone
On 2011-08-26, at 11:52 AM, hideki nara <hdknr at ic-tact.co.jp> wrote:
> Andreas, I'm with you.
> Both Check Session EP and UserInfo EP look two different OAuth
> Protected Resources to me.
> To make things simpler, I wish that the Connect flow is equal to the
> OAuth flow as much as possible and
> things special in Connect would be implemented in token(claims)
> structure and protected resource calls.
> hideki nara
> 2011/8/26 Andreas Åkre Solberg <andreas.solberg at uninett.no>:
>> I assume you have considered this idea already, and possibly rejected it for some reason?
>> The idea is that the ID Token and the User Info Access Token is two independent tokens, with separate (OAuth) scope; let's say 'openid-session' and 'openid-userdata'. The RP may indicate which of the token is needed in the Authentication request. The most common use case would be to start with doing an authentication request with 'scope=openid-session'.
>> The RP may get an User data access token by sending a refresh token request to the token endpoint using the refresh token, and the scope set to 'openid-userdata'.
>> One benefit of this would be that the ID Token will be received with a token_type, leaving it more open to support other token types in the future. You will also be able to get expires_in and potentially more meta attributes about the token.
>> As I see it this will be very inline with the OAuth spec, and may be easy to get working with existing OAuth 2.0 libraries.
>> There is a drawback that this would require an additional roundtrip to get both tokens. On the other hand; if providers issue user data access tokens with long duration; these probably be cached locally with the RT user account; and may be used to refresh user data may be on a regular basis (back channel, without the user present; this way the de-provisioning problem also could be solved: BTW: we need a 'userdoesnotexistsanymore' error code in user info). Then there would be no need to request an user data access token every time the user logs in.
>> There also might potentially be a use case for a RP to ask for a User Data access token (scope=openid-userdata in the initial request, without even establishing a session (no id_token needed). In example there are book shops that give students 'offers', and educational identity federations may help verifying that a person is a student. This could be part of the flow when purchasing a book, to ask the educational institutions user info endpoint if the person is a student or not; but the book store would not like the user to be able to login using his educational account, therefore establishing a session might be unnecessary. BWT: The current ID Token has an issue with the user_id, which leak privacy in the case where the RP not necessarily need to recognize the user again the second time he/she enters. (In SAML we have transient nameID).
>> I assume there will be extensions added to OpenID that would involve granting access to data of the user, that does not fully fit into the user info service; say in example that you would like to extend OpenID with a standardized API for accessing calendar data; issuing 'openid-calendar' access token to access a CalDAV endpoint for modifying the user's calendar. These extensions would be 'more familiar' to the OpenID consumers, if they were already used to obtaining additional tokens using the refresh token.
>> The fact that there is not in the current OAuth draft allowed to use refresh_tokens in implicit grant flow, may be a show stopper.
>> If we continued and said that the ID Token would be a transparent access token as well; and that it was required to use the check_session service to translate it into a JWT; then we could make the spec even simpler by removing the refresh session service, and instead refresh the id token using the token service with the refresh token as a grant_type. I see that this would include yet another round trip, which probably is not wanted, but I'm just thinking out load to try to understand this better..
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
More information about the Openid-specs-ab