[Openid-specs-ab] Response types clarification

Nat Sakimura sakimura at gmail.com
Wed Feb 22 02:11:52 UTC 2012


Yes.

As I understand, OAuth's response_type parameter tells what is to be
returned by the Authorization Endpoint.
We should stick to the semantics of it and should not alter it.

Perhaps we could state it in our specs, but that actually is something that
OAuth spec. really should do.

FYI, I wrote a blog post with a table showing what are to be returned in
each cases.

Hope this helps.

http://nat.sakimura.org/2012/02/22/the-relationship-between-endpoint-responses-and-response_type-scope-pair/


=nat

On Wed, Feb 22, 2012 at 7:53 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> I agree with Breno, keeping scopes and response types separate will cause
> fewer problems down the road.
>
> We have a number of new response types registered,  (I may have to hurt
> the next person who talk about them being com posable.)
>
> Each response_type clearly defines what is returned from the authorization
> server, and how it is to be returned (ignoring grey area for post message).
>
> The openid scope makes the protocol openid asking for a authentication
> grant.  e.g. Do you want to log into x and give them access to your
> user_id.   Simple.
>
> The openid protocol requires that id_token is always returned from the
> token endpoint when exchanging code.  Simple.
>
> The registered responstypes define what is returned from the authorization
> endpoint and how.  Simple.
>
> Removing some of the return_types and overloading the openid scope with
> more semantics is more complicated.
>
> My opinion
> John B.
>
>
> On 2012-02-21, at 7:16 PM, Breno de Medeiros wrote:
>
> > 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
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120222/319ec050/attachment-0001.html>


More information about the Openid-specs-ab mailing list