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

Brian Campbell bcampbell at pingidentity.com
Fri Aug 4 12:52:27 UTC 2017


>
> 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.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20170804/3198cc8d/attachment.html>


More information about the Openid-specs-fapi mailing list