[Openid-specs-ab] Multiple response types

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

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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111103/f2945f75/attachment.html>
-------------- 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/f2945f75/attachment.p7s>