[Openid-specs-fapi] JWT Secured Authorization Response Mode (#155)

[Brian Campbell]

On Thu, Aug 16, 2018 at 7:00 AM Torsten Lodderstedt <torsten at lodderstedt.net>
wrote:

> Hi Brian,
>
> > Am 15.08.2018 um 23:58 schrieb Brian Campbell <
> bcampbell at pingidentity.com>:
> >
> > 4.3 Processing Rules has, "Check the signature of the JWT using the JWK
> set of the expected issuer. Note: the client MUST obtain the JWK set from
> local data and MUST NOT follow the iss claim of the JWT to obtain key
> material. This is done to prevent DoS (see Security Considerations)"
> >
> > That sounds to me like it rules out the way that signature verification
> keys are typically obtained for ID Token verification where the OP's
> metadata points to a jwks_uri where keys can be retrieved and more seamless
> key rotation is possible. See 10.1 and 10.1.1 of OIDC Core for example. The
> jwks_uri is defined for both OP metadata and AS metadata.
> >
> > That verification key retrieval pattern from OIDC works pretty well as
> far as I know. I don't think this JWT Secured Authorization Response Mode
> should depart from it. As written it sounds like a client would have to
> somehow separately store/maintain keys for an AS for sole purpose of
> verifying a JWT Secured Authorization Response.
>
> My assumption is the client obtains the key material from the OAuth or
> OpenID Configuration of the AS/OP in advance. The clients needs anyway to
> obtain the endpoint data and memorize the issuer it sent the user agent to
> (mix up prevention). Linked to this data, it stores the respective key/keys
> or JWKS_URL.
>

Yes. That. But the content of the JWKS_URL may need to be retrieved again
or for the first time if a cache has expired or the kid value of the token
doesn't match a key in the cached JWKS.


>
> > I think there are other ways to address the stated security concerns -
> response size restrictions, caching, timeouts, etc. - and these things are
> already presumably happening because the typical OIDC ID token flow does
> what this draft wants to prohibit. And there are a lot of OIDC deployments.
>
> Good point. OIDC Core (
> http://openid.net/specs/openid-connect-core-1_0.html#Security) does not
> discuss this attack angle. From your perspective, what is the typical way
> to detect crafted/modified ID Tokens in the id_token flow?


 Checking the signature. But if the issuer isn't known or expected, don't
go trying to find keys for it, just reject the token.


>
> > Or maybe I"m misinterpreting the text? If that's the case, some
> clarification is needed I think.
>
> I tried :-)
>

I'm trying also :)

-- 
_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/20180817/c012679a/attachment-0001.html>