[Openid-specs-fapi] Ensuring one-time use of request JWTs registered at the request JWT endpoint
thomasclinganjones at gmail.com
Sat Aug 5 02:19:26 UTC 2017
Guaranteeing one time use on an unreliable network (with retries built in)
is a thankless task. What exactly is the threat that needs to be mitigated?
On Thu, Aug 3, 2017 at 10: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
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-fapi