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

Tom Jones 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?
  ..tom

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?
>
> 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
>



-- 
..tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20170804/d4f238ae/attachment.html>


More information about the Openid-specs-fapi mailing list