[Openid-specs-ab] Multiple response types

[Roland Hedberg]

3 nov 2011 kl. 17:10 skrev John Bradley:

> Part of the problem is the wording of OAuth conflating Implicit  client (client can't keep a secret) and token response type.
> 
> return_type communicates what you want in the response from the Authorization server, and how the Authorization server SHOULD return it.

It's still a bit unclear to me.

It's not clear to me what is supposed to happen when you have both 'code' and 'token' in the return_type.
Not when it comes to what should eventually be returned to the client but in how is should be returned.

Given the standard text you cite below:

	'a successful response MUST include both an Access Token
	and an Authorization Code as defined in the OAuth 2.0
	specification.'

My interpretation if this is that if the authorization server uses a redirect then both 'code' and 'access_token' must be among the parameters.
And that it is not ok to just return 'code' and expect the client to get the access_token by using the Token Endpoint.
So it's more like the OAuth2 implicit flow except for the fact that you get a 'code' to.

Coming back to the second part of my question: if both 'code' and 'access_token' is return together what use does the client have of 'code'.
The only thing I can imaging is to get a 'refresh_token'.
And since the Token Endpoint has to return an 'access_token' together with the 'refresh_token' if we are going to abide by the OAuth specification there is still the question about if this 'access_token' is the same as the one returned in the redirect.

It would be nice if the text elaborated a bit on how the multivalued response-types influences the flows.

> Now if I understand Breno correctly the SHOULD has to do with HTML 5 post message.  If a client registers a special redirect_uri the Authorization server would use post message to the parent window or something like that.
> 
> I have fixed the examples you have pointed out.
> 
> John B.
> 
> 
> Draft 7 of Standard has the breakdown.
> 
> 4.2.1.  How to Get an Authorization Code, Access Token, and ID Token
> 
>    The Authorization Server MUST support both the ""code"" and the
>    ""id_token token"" "response_type".
> 
>    The client may request any OAuth 2.0 registered response type
>    supported by the Authorization Server.
> 
>    The OAuth 2.0 specification documents two response types:
> 
>    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".
> 
>    token  When supplied as the value for the "response_type" parameter,
>       a successful response MUST include an Access Token as defined in
>       the OAuth 2.0 specification.  Both successful and error responses
>       MUST be fragment-encoded.  No ID Token is provided to the client.
> 
>    Openid Connect supports these additional flows [RESPONSE.TYPES] that
>    have been registered:
> 
>    id_token token  When supplied as the value for the "response_type"
>       parameter, a successful response MUST include both an Access Token
>       as well as an ID Token.  Both success and error responses SHOULD
>       be fragment-encoded.  Authorization Servers MUST support this
>       "response_type".
> 
> 
> 
> Sakimura, et al.                                                [Page 8]
>                  OpenID Connect Standard 1.0 - draft 07    November 2011
> 
> 
>    code token  When supplied as the value for the "response_type"
>       parameter, a successful response MUST include both an Access Token
>       and an Authorization Code as defined in the OAuth 2.0
>       specification.  Both successful and error responses SHOULD be
>       fragment-encoded.
> 
>    code id_token  When supplied as the value for the "response_type"
>       parameter, a successful response MUST include both an
>       Authorization Code as well as an ID Token.  Both success and error
>       responses SHOULD be fragment-encoded.
> 
>    code id_token token  When supplied as the value for the
>       "response_type" parameter, a successful response MUST include an
>       Authorization Code, an ID Token, and an Access Token.  Both
>       success and error responses SHOULD be fragment-encoded.
> 
> On 2011-11-03, at 9:01 AM, Roland Hedberg wrote:
> 
>> Hi!
>> 
>> I have a bit of a problem getting my head around multiple response types and what it means.
>> 
>> If the client specifies "code token" or for that matter "code id_token token" as response types in an authorization request.
>> 
>> Is this to be regarded as an implicit flow, code flow or neither ?
>> 
>> Assuming it is a 'code flow'-like flow then the client should be able to use the authorization code received to get a token from the token endpoint.
>> 
>> What is the relationship between the token information returned in the redirect URI and the response to the access token request ?
>> Are they expected to be the same except for refresh_token which may appear in the access token response?
>> 
>> By the way, in the examples in 4.3.4.1 access_token is wrongly named token.
>> 
>> -- Roland
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>