[Openid-specs-fapi] Ensuring one-time use of request JWTs registered at the request JWT endpoint
philippe.leothaud at 42crunch.com
Fri Aug 4 13:38:20 UTC 2017
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,
that Auth Request must be "made as defined in
Authorization code flow Auth Request), where it's said that the nonce is
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.
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?
>> 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
>> > 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
>> > at the request JWT endpoint
>> > It appears to me that one-time use of request objects registered by URI
>> > 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
>> > enforced, but the URL is world readable.
>> > 2. Malicious JS code in the browser GETs the request_uri 3. The
>> > 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
>> > 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
> *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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-fapi