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

Nat Sakimura nat at sakimura.org
Sat Aug 5 04:49:43 UTC 2017


Actually, it should result in a errata on the OIDC core. 

On Aug 4, 2017, 10:45 PM, at 10:45 PM, Philippe Leothaud via Openid-specs-fapi <openid-specs-fapi at lists.openid.net> wrote:
>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
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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/20170805/f29d30af/attachment-0001.html>


More information about the Openid-specs-fapi mailing list