[Openid-specs-ab] Nonce and Authorization flow vs Implicit flow
Richer, Justin P.
jricher at mitre.org
Mon Jul 23 21:23:08 UTC 2012
The only way to really switch between the code flow and the implicit flow is the response_type parameter -- using any other parameter to hint for this is dangerous and prone to error. All other parameters MAY be used in either flow. For example, you can have "nonce" in any profile, and the server *needs* to accept it, but it's *required* for an implicit client to send it for security reasons (I'll let others fill in the details on the exact reasoning behind that?).
This all grows out of the OAuth2 core spec, which actually defines four different flows (auth code, implicit, client credentials, and password) with an extension mechanism (that has been used for things like assertion flows).
On Jun 6, 2012, at 5:08 PM, Magnus Andersson wrote:
First a short introduction: My name is Magnus, I'm currently implementing an OpenID Connect server as per the draft specifications. I have a concern about the recent update to the drafts where nonce is removed from basic profile authorization request.
As I read it after the last update, I can not longer determine which request parameters are allowed/should to be present for the authorize endpoint until after I have read the content of response_type and thus determined if the flow is the 'implicit flow' or 'code flow'. The spec openid-connect-implicit have nonce listed as OPTIONAL but the openid-connect-basic does not expect it to be present at all.
Common validation libraries in web frameworks won't easily handle when the presence of one request parameter directly depends on another parameter's data. It also suggests too many responsibilities, in my opinion. This makes implementation unnecessarily complex.
If I'm missing something obvious please tell. I'm very new to OpenID Connect so I recognize I might have missed something obvious.
If I am on to something I would suggest:
either option to have two different endpoints in the Discovery service for authorization, one for each of the two different kinds of authorization flows
or only one single set of required/optional parameters per endpoint regardless of how many flows it supports.
My preference is the first alternative as it would reflect how the specs are split up today and make flows more visible. To me it is non-obvious what stipulates code flow or implicit flow mode, I have had to read both documents and compare to figure out what the difference is.
E-post: magnus.andersson at solvies.se<mailto:magnus.andersson at solvies.se>
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab