Mandate at_hash check in the ID Token from the token endpoint

Issue #150 closed
Nat Sakimura created an issue

In OIDC, at_hash is optional.

Our intention is to protect all the messages so we need to mandate it to be included and the check to be performed.

Comments (4)

  1. Joseph Heenan

    I wonder if we should explain the full security model somewhere, unless it's already covered somewhere else?

    The way I see it there's a chain here where a weakness at any point could allow a rogue access token in:

    discovery - protected by TLS cert, but I presume a client generally only fetches this once

    jwks_uri - obtained from discovery, protected by TLS cert and refreshed frequently

    id_token - validated by keys from jwks_uri

    access token - validated by hash from id_token

    That would tend to imply that we should make it clear that discovery & jwks_uri endpoints are both on a 'secure' server and (as Nat had suggested before) that people should look at techniques like TLS certificate pinning, DNSSEC, etc, etc.

    It all depends on how far we want to go. e.g. openbanking neither recommend certificate pinning (at least as far as I can see in the security specification), and I believe all bank jwks uris are hosted on a host under openbanking.org.uk, and that domain doesn't appear to have DNSSEC setup.

  2. Nat Sakimura reporter
    • changed status to open

    Good point. Perhaps can we create a separate issue for what you are pointing out? This particular one is to cover the reported potential attack.

  3. Log in to comment