[Openid-specs-ab] Multiple response types

Thu Nov 3 20:34:37 UTC 2011

On 2011-11-03, at 4:44 PM, Roland Hedberg wrote:

> 
> 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.
Standard Sec 4.2.1

'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.

They are both returned in the fragment.

> 
> 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.

The term implicit flow should probably be fragment encoded flow,  so yes both come back in the fragment like the implicit example in OAuth 2.0.

The only response_type that is not fragment encoded is code.

> 
> 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'.

Yes it can use it to get a refresh token, and id_token in the back channel.

The common use may be if the RP is not TLS enabled.

You may ask for 'code token'  and have the JS only pass back token to the home server.  The JS can use the access token to access the protected resource over TLS.
The Server exchanges code & client secret for id_token, access_token, and  refresh_token in the back channel.

It is a way to get tokens to both parts of the client without passing the access token over a unprotected channel.

> 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.

There is only one client_id so they can be the same or different, depending on the servers needs.   The one that is in the server can be refreshed so over time they will become different if they don't start that way.

The important thing is that they have the same scopes.  and if you cancel the tokens for a client_id they all get canceled.

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

I thought the new text I added cleared it up, but perhaps not enough.

Did you look at the registration spec for the return_types

John B.
> 
>> 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
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111103/657b1969/attachment.p7s>