[Openid-specs-ab] About ID Tokens being access tokens
Andreas Åkre Solberg
andreas.solberg at uninett.no
Fri Aug 26 11:42:42 UTC 2011
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..
More information about the Openid-specs-ab