<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Part of the problem is the wording of OAuth conflating Implicit client (client can't keep a secret) and token response type.</div><div><br></div><div>return_type communicates what you want in the response from the Authorization server, and how the Authorization server SHOULD return it.</div><div><br></div><div>Now if I understand Breno correctly the SHOULD has to do with HTML 5 post message. If a client registers a special <span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; ">redirect_uri the Authorization server would use post message to the parent window or something like that.</span></div><div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; "><br></span></div><div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; ">I have fixed the examples you have pointed out.</span></div><div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; "><br></span></div><div><span class="Apple-style-span" style="font-family: verdana, charcoal, helvetica, arial, sans-serif; font-size: small; ">John B.</span></div><div><br></div><div><br></div>Draft 7 of Standard has the breakdown.<div><br></div><div><div>4.2.1. How to Get an Authorization Code, Access Token, and ID Token</div><div><br></div><div> The Authorization Server MUST support both the ""code"" and the</div><div> ""id_token token"" "response_type".</div><div><br></div><div> The client may request any OAuth 2.0 registered response type</div><div> supported by the Authorization Server.</div><div><br></div><div> The OAuth 2.0 specification documents two response types:</div><div><br></div><div> code When supplied as the value for the "response_type" parameter, a</div><div> successful response MUST include an Authorization Code as defined</div><div> in the OAuth 2.0 specification. Both successful and error</div><div> responses MUST be added as parameters to the query component of</div><div> the response. All tokens are returned from the Token Endpoint.</div><div> Authorization Servers MUST support this "response_type".</div><div><br></div><div> token When supplied as the value for the "response_type" parameter,</div><div> a successful response MUST include an Access Token as defined in</div><div> the OAuth 2.0 specification. Both successful and error responses</div><div> MUST be fragment-encoded. No ID Token is provided to the client.</div><div><br></div><div> Openid Connect supports these additional flows [RESPONSE.TYPES] that</div><div> have been registered:</div><div><br></div><div> id_token token When supplied as the value for the "response_type"</div><div> parameter, a successful response MUST include both an Access Token</div><div> as well as an ID Token. Both success and error responses SHOULD</div><div> be fragment-encoded. Authorization Servers MUST support this</div><div> "response_type".</div><div><br></div><div><br></div><div><br></div><div>Sakimura, et al. [Page 8]</div><div> </div><div> OpenID Connect Standard 1.0 - draft 07 November 2011</div><div><br></div><div><br></div><div> code token When supplied as the value for the "response_type"</div><div> parameter, a successful response MUST include both an Access Token</div><div> and an Authorization Code as defined in the OAuth 2.0</div><div> specification. Both successful and error responses SHOULD be</div><div> fragment-encoded.</div><div><br></div><div> code id_token When supplied as the value for the "response_type"</div><div> parameter, a successful response MUST include both an</div><div> Authorization Code as well as an ID Token. Both success and error</div><div> responses SHOULD be fragment-encoded.</div><div><br></div><div> code id_token token When supplied as the value for the</div><div> "response_type" parameter, a successful response MUST include an</div><div> Authorization Code, an ID Token, and an Access Token. Both</div><div> success and error responses SHOULD be fragment-encoded.</div><div><br></div><div><div>On 2011-11-03, at 9:01 AM, Roland Hedberg wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi!<br><br>I have a bit of a problem getting my head around multiple response types and what it means.<br><br>If the client specifies "code token" or for that matter "code id_token token" as response types in an authorization request.<br><br>Is this to be regarded as an implicit flow, code flow or neither ?<br><br>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.<br><br>What is the relationship between the token information returned in the redirect URI and the response to the access token request ?<br>Are they expected to be the same except for refresh_token which may appear in the access token response?<br><br>By the way, in the examples in 4.3.4.1 access_token is wrongly named token.<br><br>-- Roland<br><br><br>_______________________________________________<br>Openid-specs-ab mailing list<br><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></div></blockquote></div><br></div></body></html>