[Openid-specs-ab] Nonce and Authorization flow vs Implicit flow

John Bradley ve7jtb at ve7jtb.com
Mon Jul 23 21:20:36 UTC 2012


It is the client that determines the flow.  

If it sends response_type=code then it is the code flow or 'token id_token' for the implicit.

The server always passes through nonce if present.  

A basic client using the code flow is not required to send it,  but may send it.

Any flow where the id_token is delivered in the front channel MUST send nonce in the request.

The interesting question is if the authorization server must throw an error if it receives a request without nonce and the response_type is not 'code'

John B.

On 2012-06-06, at 5:08 PM, Magnus Andersson wrote:

> Hi everyone
> 
> 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.
> 
> Kind regards
> Magnus Andersson
> 
> -- 
> 
> 
> Magnus Andersson
> Solvies AB
> Telefon: +46-738-403885
> E-post: magnus.andersson at solvies.se
> Webplats: http://www.solvies.se
> 
> 
> _______________________________________________
> 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/20120723/3a108eef/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4937 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120723/3a108eef/attachment.p7s>


More information about the Openid-specs-ab mailing list