[Openid-specs-fapi] Ensuring one-time use of request JWTs registered at the request JWT endpoint

Philippe Leothaud philippe.leothaud at 42crunch.com
Fri Aug 4 13:38:20 UTC 2017


Hi

There is something inconsistent in the OIDC core spec at this level, as in
the hybrid flow :
   - as Brian underlines the ID Token must contain a nonce claim,
   - but on the other hand when generating the Auth request,
https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest says
that Auth Request must be "made as defined in
https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest" (the
Authorization code flow Auth Request), where it's said that the nonce is
optional...

The hybrid flow implementations I've seen in the wild (and notably Azure AD
default behaviour) use a nonce, though.

So yes, it'd be better to state explicitely that it's mandatory, IMHO.

Thanks,

Philippe



On Fri, Aug 4, 2017 at 2:52 PM, Brian Campbell via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> I thought that `nonce` was required in Hybrid Flow, but is apparently not.
>>
>
> http://openid.net/specs/openid-connect-core-1_0.html#HybridIDToken says
> that nonce is required in Hybrid Flow.
>
> I'd always thought that nonce was required when an ID Token would be
> returned in the front channel. But a literal reading of the spec would
> suggest it is required with any of the response types that result in the
> implicit or hybrid flow.
>
> On Thu, Aug 3, 2017 at 11:47 PM, Nat Sakimura via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net> wrote:
>
>> Good points.
>>
>> 1. One-time use of `request_uri`
>>
>> By this, I meant that `request_uri` could be used only once against the
>> authorization endpoint. I did not mean that the GET to `request_uri` value
>> should fail for the second access. I understand that the text is ambiguous
>> and needs to be clarified.
>>
>> 2. Attacker re-registering the request object
>>
>> Now, as to the problem of the replay against the request object endpoint,
>> the client needs to include a nonce.
>> I thought that `nonce` was required in Hybrid Flow, but is apparently not.
>> So, it needs to be stated.
>> Once `nonce` is there, iss (client_id) + redirect_uri + nonce become
>> globally unique.
>> It will act as the unique identifier for the request object.
>> The AS needs to check it to find if it has been used before.
>>
>> Unless the request object has `exp`, the AS has to maintain the state
>> indefinitely, which is not practical.
>> So, we also need to state that `exp` needs to be included and it should
>> expire in a short period of time.
>>
>> With it, the request object endpoint can reasonably reject the replay.
>>
>> What do you think?
>>
>> Nat
>> --
>> PLEASE READ :This e-mail is confidential and intended for the
>> named recipient only. If you are not an intended recipient,
>> please notify the sender  and delete this e-mail.
>>
>>
>> > -----Original Message-----
>> > From: Openid-specs-fapi
>> > [mailto:openid-specs-fapi-bounces at lists.openid.net] On Behalf Of
>> Vladimir
>> > Dzhuvinov via Openid-specs-fapi
>> > Sent: Wednesday, August 2, 2017 4:22 PM
>> > To: openid-specs-fapi at lists.openid.net
>> > Subject: [Openid-specs-fapi] Ensuring one-time use of request JWTs
>> registered
>> > at the request JWT endpoint
>> >
>> > It appears to me that one-time use of request objects registered by URI
>> cannot
>> > be guaranteed, unless read access to the request_uri is strictly
>> limited to
>> > the AS only.
>> >
>> > Consider the following scenario:
>> >
>> > 1. Client registers request object at request_uri, one-time GET policy
>> is
>> > enforced, but the URL is world readable.
>> > 2. Malicious JS code in the browser GETs the request_uri 3. The
>> authorization
>> > request will fail due to invalid request_uri 4. The malicious JS code
>> can still
>> > re-register the request object as many times as it wants
>> >
>> >
>> > The statement in 7.2 may also need to be revised then:
>> >
>> > http://openid.net/specs/openid-financial-api-part-2.html#request
>> >
>> > > The request object needs to be signed for the client authentication
>> > > and as the evidence of the client submitting the request object, which
>> > > sometimes is called 'non-repudiation'.
>> >
>> > If the request_uri is world readable, even if the AS takes measure to
>> make
>> > it hard to guess, the end-user / user agent will always be able to get
>> it and
>> > re-register it, which means the signature doesn't really hold as
>> evidence of
>> > the client submitting the request JWT.
>> >
>> >
>> > Vladimir
>>
>>
>> _______________________________________________
>> Openid-specs-fapi mailing list
>> Openid-specs-fapi at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20170804/f93d58c8/attachment-0001.html>


More information about the Openid-specs-fapi mailing list