1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

ID token signature validation

Issue #711 new
Dima Postnikov created an issue

FAPI specifications need to be explicit if ID token signature needs to be validated by a client.

Common sense says “yes“, we have just found out that some implementations do it and some don't.

More discussion: https://gitlab.com/openid/conformance-suite/-/issues/1375

What does formal analysis say about it? Is it a control we rely on?

Comments (10)

  2. Dima Postnikov reporter

    Thanks Flip. Interesting. Don’t remember that discussion….

    I guess I am coming from an ecosystem perspective, where legal liability can be attached to the signature.

    ID token signature gives clients ability to prove that the information indeed came from the right IDP and hasn’t been tampered with. This helps with potential disputes.

    Currently, clients seem to choosing consciously, randomly or without knowing (if using existing SDKs) to verify token signature or not when ecosystems or the specs don’t tell them to.

    If there is no security or interoperability benefit, perhaps this requirement should go into message signing spec then… Optional requirement. And ecosystems like us will mandate it and request the update to the conformance test anyway (at least for our profile).

  3. Filip Skokan

    ID token signature gives clients ability to prove that the information indeed came from the right IDP and hasn’t been tampered with. This helps with potential disputes.

    The clients don’t need that ability during regular operation runtime, else the security analysis would show such.

  4. Dima Postnikov reporter

    What is the regular operation runtime for FAPI based ecosystems?

    I understand that it has been concluded that there is no security benefit associated with ID token signature verification assuming it comes via secure channel. Although… it depends on a context, I am pretty sure I can find scenario when it can be misused. May be this is ecosystem specific and should go into the ecosystem profile.

    OP is expected to sign the token using it’s own key; not using somebody else’s key or not supplying a token issued by someone else. We test for it, I assume. Once of during certification, if the certification is used. We also have FAPI ecosystems that don’t use certifications for OPs but might use FAPI certified SDKs for clients.

    Is it a big deal for a client to check it as well, for every ID token issued? Some do already anyway.

    If there is also no interoperability benefit (?) then perhaps it should go into message signing profile… for non-repudiation and liability reasons mentioned above.

  5. Filip Skokan

    What is the regular operation runtime for FAPI based ecosystems?

    Apologies, that’s not a term we usually use in this group. What I meant is simply that during Authorization Response processing this ability you describe is not needed.

    Is it a big deal for a client to check it as well, for every ID token issued? Some do already anyway.

    Yes it is a big deal for some.

    For example clients running on edge runtimes (e.g. Cloudflare Workers, Vercel’s Edge Runtime, Netlify Edge Functions, and others). These environments have one trait in common that they usually run on the same edges as CDNs in complete isolation with no server state carried over between requests, that means resolving the OP's JWKS every time they’re processing a response. The feedback I got from users was that it was unacceptable behaviour.

    for non-repudiation and liability reasons mentioned above.

    Wouldn’t that also call into question the optionality of OIDC?

    OP is expected to sign the token using it’s own key; not using somebody else’s key or not supplying a token issued by someone else. We test for it, I assume. Once of during certification, if the certification is used. We also have FAPI ecosystems that don’t use certifications for OPs but might use FAPI certified SDKs for clients.

    The RPs are still expected to validate the ID Token’s JWT Claims Set as per usual. It’s merely that the TLS server validation from client<>token endpoint is used to validate the issuer in place of checking the token signature.
    A scenario where this OIDC affordance cannot be used would mean that TLS cannot be trusted in which case the client might as well get different JWKS served and so checking the signature would be pointless.

  6. Aaron Parecki

    I agree that it should not be validated in the baseline profile for the reasons Filip explained, and also because OpenID core doesn’t require validation either. Dima brought up a good non-repudiation reason for validating the token, so I could see puting in the requirement to validate the signature in the message signing profile.

  7. Dave Tonge

    We discussed on the call today. There was agreement on the call not to add to the main security profile, but to maybe add either to “Message Signing” or a new spec about using OIDC with FAPI2 or in implementation doc.

  9. Ralph Bragg

    From my perspective, given that we have ecosystems that send id_tokens around (querying content and relying on the information for tight linkage to consent records eg obie) and they expect the content of this to be honoured or validated and relied on post the issuance from the token endpoint then not having this is an issue. A lot of ecosystems will expect this to be enforced - given that most eocsystems that were involved in are using some variant of fapi 2 message signing it would be useful if it his was added in to the message signing spec as a requirement.

    ‌

    Otherwise it’ll just be made mandatory in cbuae, connectid, open finance and insurance brazil and other places which will mean at the very least relying parties will need a test suite that validates that they check and process the signature correctly for certification.

  11. Log in to comment
Assignee
–
Type
proposal
Priority
major
Status
new
Component
FAPI2: Message Signing
Milestone
FINAL
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!