[Openid-specs-ab] About ID Tokens being access tokens
ve7jtb at ve7jtb.com
Fri Aug 26 18:27:49 UTC 2011
An important issue for RP is perceived latency. That is why they don't want to have to do a extra round trip to get the id_token.
If you have a JS client that needs an access token as well as a id_token it would need to make two separate implicit calls to at the authorization endpoint.
I suspect that is the biggest problem. For a server it is also several round trips that each may require user consent. From a user experience point of view one trip to the OP is enough.
We are running into a OAuth issue. There should be a standard way to request multiple tokens.
We have half of it sort of. For response type you can register response_type=code token id_token
To indicate that you want a code, token , and id_token returned in the fragment of the http redirect.
response_type is about what you want in the redirect response not necessarily what tokens you want.
In the case where you only want code in the redirect, scope is about the only place to say that you want a access token for the user-info endpoint and a id_token returned from the token endpoint.
That was why I was proposing that the openid scope be about the id_token and we define other scopes for user-info.
That way scope controls what tokens you want (perhaps others for portable contacts etc), and response_type controls how you get them.
There was a proposal to the allow multiple access tokens to be returned by making it an array or structure.
That didn't happen, so we are on our own to define how multiple tokens are returned.
That makes it more complicated to use standard libraries. I don't think we are the only ones with this issue
The other issue with treating a id_token as an access token is that some frameworks don't make it easy to get at the contents of the token used to authenticate to the endpoint.
I suspect that is going to be a problem with them using any sort of JWT as an access token.
On 2011-08-26, at 4:42 AM, Andreas Åkre Solberg wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4767 bytes
Desc: not available
More information about the Openid-specs-ab