[Openid-specs-ab] Response types clarification

Breno de Medeiros breno at google.com
Tue Feb 21 22:16:32 UTC 2012


On Tue, Feb 21, 2012 at 14:07, Justin Richer <jricher at mitre.org> wrote:
> On not being OpenID: I would say that if you're not getting an ID Token
> back, you're not doing OpenID Connect, you're just doing OAuth2. If you
> happen to be doing OAuth2 against something that has a User Info Endpoint,
> that's fine, but it's not binding you to the user's session. It's definitely
> the right thing to avoid mucking about with OAuth2 wherever possible.
>
> But the question being addressed below was "how do I know when to include
> the ID Token?", and I think it should break down as follows (assuming user
> grants access and all else is validated):
>
> - if the request to the token endpoint includes the scope 'openid', throw
> the id token into the JSON response
> - if the request to the authorization endpoint is for type 'token' and the
> scope includes 'openid', throw the id token into the fragment
> - if the request to the authorization endpoint is for type 'code id_token'
> and the scope includes 'openid', throw the id token into the fragment along
> with the code (again, avoids the query parameter leakage issue brought up
> before)
> - if the request to the authorization endpoint is for type 'code token' and
> the scope includes 'openid', throw the id token and the access token into
> the fragment along with the code
>
> What I'm saying is that #3 above is an odd special case that could be
> subsumed by #4 above. This all gets rid of the need for the id_token
> response type entirely. Apart from being a breaking change, I don't see how
> this doesn't cover the use cases described below.

I don't see why this is simpler. It's actually more obscure to
developers. The scope 'openid' refers to scope of access -- namely the
request to learn the user's identifier at the issuer.

>
>  -- Justin
>
>
> On 02/21/2012 04:48 PM, John Bradley wrote:
>
>
> On 2012-02-21, at 5:41 PM, Justin Richer wrote:
>
> John, thanks for the background. This leaves me with a major question
> though:
>
> That was the way we originally had it.   Later on people thought that using
> the OAuth multi-response type was more OAuth friendly.
>
> Originally if you had the scope openid:
> 1 response_type=code   both code and id_token were query encoded in the
> response
>
>
> Maybe I'm missing something, but in the "code" flow, you don't get back an
> id_token in that response. You get back a code, and that code can be
> exchanged for an access token and an id_token, since you asked for something
> that includes the "openid" scope. From Standard, section 2.2.1:
>
> code When supplied as the value for the response_type parameter, a
> successful response MUST include an Authorization Code as defined in the
> OAuth 2.0 specification. Both successful and error responses MUST be added
> as parameters to the query component of the response. All tokens are
> returned from the Token Endpoint. Authorization Servers MUST support this
> response_type.
>
> So the whole issue of query-encoding the id_token isn't even an option here.
> It *is* an option if you're asking for something akin to "code id_token",
> but that wasn't on the table. In the current spec, those are both defined as
> fragment encoded anyway.
>
>
> Having id_token returned in the front channel was one of the early must
> haves from the major IdP.   Given that in the early days we returned
> id_token query encoded in the front channel and from the token endpoint.
> It looked like a hack.   There was no way to change the semantics of code.
> With the multi token response type change around draft 19 of OAuth I think,
>  Google and Facebook decided that was the best way to indicate the
> response_type, rather than overloading the semantics of scopes.
>
> Currently if you ask for code it is defined in the OAuth 2 core spec and you
> get code back just as you would expect, the same goes for token.  We avoided
> reinterpreting the OAuth spec as much as possible.
> The permissible way to ask for multiple tokens is the return type and that
> is what we are currently doing.
>
>
> 2 response_type=token  both access_token and id_token were fragment encoded.
>
> There was no way to just get code or access_token, and no way to get just
> id_token.
>
>
> The former, yes, there is: just don't include the "openid" scope. The
> latter, no. But if you ask for a token with just the "openid" scope and
> don't ask for any other permissions, the server *could* give you a null or
> empty or otherwise useless access token there, if it wanted to. I agree that
> if this is a real and viable use case, then it should be a separate kind of
> response_type, but I'm not seeing that right now.
>
> The thing is that if you don't include the openid scope you are not doing
> openid Connect and our spec has nothing to say in the matter.   So removing
> the openid scope so that the IdP can't tell if it is a connect request or
> some other OAuth request is not a real option.
>
> The only thing I might change at this point on response_type if I had a do
> over would be to use underscores rather than spaces to reduce confusion.
> Other than that I don't think we have a problem.
>
> In reality a client will only use a single response type appropriate for it.
>   They are not dynamically changing these things.   If you want code as a
> query parameter just ask for 'code' all the options are available to the
> clients without confusing it with the scopes.
>
>
> It was simpler I will give you that.
>
> It is a bit different from adding id_token to the token endpoint in that
> there is no OAuth mechanism for controlling the response from the endpoint.
> I suppose the alternative would have been to add an extra parameter to the
> token endpoint request to say if you wanted a id_token.
>
>
> No, again, that's what the scope already handles. If we didn't have a
> standardized scope value, then I'd agree with this.
>
> Again if you remove the openid scope it is not openid.  That is the scope
> that asks for the user_info endpoint and the user_id.
>
> John
>
>  -- Justin
>
> - just using "token" instead of all combinations of id_token and token ?
>
> The response type "token" could cause the OP to return both the id_token and
> the access token in the fragment, which is similar to the response of the
> tokens endpoint. I know this would return tokens the client is potentially
> not interested in. But this seems to be accepptable for the code response
> type.
>
> I actually rather like this approach. It keeps the question of whether or
> not you want OpenID confined to the value of the 'scope' field (that is,
> presence of an 'openid' value in there), and it makes serialization of the
> ID Token just a part of the access token output, like the code flow with the
> token endpoint. Of course we still have to profile how it gets encoded, but
> it's ultimately another field in the token output.
>
> -- Justin
>
> Am 20.02.2012 20:44, schrieb John Bradley:
>
> Response types are single values.   (I am starting to hate Erin's
> compromise)
>
> The response types are documented in:
> http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html
>
> The response types "code id_token",  "id_token token", and "code id_token
> token"  MUST return a id_token and the response SHOULD be fragment encoded.
>
> Now you are asking yourself why is that SHOULD be fragment encoded as
> opposed to MUST be fragment encoded.
>
> The reason for that is that the response_type registration is leaving wiggle
> room to use the same response type with post message as well.
>
> For that to work the client would need to register a JS Origin and DOM
> Channel Names(or pick a fixed strings).  We did stub in post message
> configuration parameters, but removed them due to there not being a OAuth
> spec yet.
>
> Probably more than the yes you were looking for, but the history provides
> some perspective.
>
> John B.
> On 2012-02-20, at 3:52 PM, Torsten Lodderstedt wrote:
>
> Hi John,
>
> thanks for the clarification.
>
> So all response types containing the string value "id_token" cause the
> authorization server to directly return a id_token (along with all other
> parameters) to the client via fragment?
>
> regards,
> Torsten.
>
> Am 20.02.2012 19:48, schrieb John Bradley:
>
> Inline
>
> On 2012-02-20, at 3:30 PM, Torsten Lodderstedt wrote:
>
> Hi all,
>
> I'm trying to catch up with the Implementors Draft and need some advice from
> the group.
>
> Is it correct that "code" is the only response type, which is delivered to
> the client via URI query parameter? For all other response types, the
> response parameters are encoded within the URI fragment.
>
> Yes
>
> Furthermore, is the client always issued an access token _and_ an id_token
> for scope "openid" and response type "code"?
>
> The response from the Authorization server is code as was asked for.
>
> The Token endpoint includes id_token in it's response as an extra parameter.
>
> So strictly speaking Yes id_token is always issued if the scope is 'openid'
> (scope is a single value with spaces, so don't say includes) and the
> response_type is code.
>
> However the response type is code and only code.
>
> The id_token is only returned if code is exchanged at the token endpoint for
> and access_token and id_token.
>
> So I suppose you could avoid getting id_token by not exchanging code, but I
> don't think anyone is going to think that is a good idea.
>
> The problem is that response)type only controls what comes back from the
> Authorization endpoint, and not the token endpoint.
>
> The only option we found was overloading a scope to change the behaviour of
> the token endpoint to return the extra value.
>
> The token endpoint response is direct, so size is not a big issue.  It was
> simpler to always return it from that endpoint than create a complicated way
> of asking for it from the token endpoint.
>
> Worst case the response is a bit bigger, but the client ignores the extra
> parameter.
>
> John B.
>
> thanks in advance,
> Torsten.
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>



-- 
--Breno


More information about the Openid-specs-ab mailing list