In order to verify the payload, you need a public key. You typically get the public key in a protocol specific way, you should review how openid connect handles this, for details.
Sometimes to get the key, you end up needing to decode both the protected header and the payload. It's unfortunate that you may need to decode the payload, because you can possibly fail to verify at this point, and you are looking at unverified / tampered data. However some protocols force you to do this. Ideally, you would check the header only, discover the key, verify the header and payload and then apply validation to both. If you are building a new protocol, I'd recommend attempting to take this approach, because it offers the possibility of building safer APIs. If you are building a library that has to support all / older protocols... I recommend taking an approach that clearly distinguishes decoding from verifying, for example: https://github.com/panva/jose/blob/main/docs/functions/util_decode_protected_header.decodeProtectedHeader.md https://github.com/panva/jose/blob/main/docs/functions/util_decode_jwt.decodeJwt.md vs https://github.com/panva/jose/blob/main/docs/functions/jwt_verify.jwtVerify.md Hopefully this is helpful. OS On Thu, Oct 12, 2023 at 1:55 PM Les Hazlewood <[email protected]> wrote: > Hello folks - I hope someone can help answer a quick question: > > https://datatracker.ietf.org/doc/html/rfc7515#section-5.2 does not make > any indication if a Claims payload may be parsed before signature/MAC > verification. > > I am a JOSE library author/maintainer and I've had application developers > request the ability to look at information in a Claims payload to help find > the key used to verify the signature/MAC. Their concerns are that an > Identity Provider may use a key id (kid) in the header that is not > guaranteed to be globally unique, and they may need other information in > the Claims (e.g. issuer) to help them locate the appropriate key. > > My response was that there are many other options like jku, jwk thumprints > as key ids, x5t, etc, that all mitigate this concern, and I dislike parsing > payloads that haven't been cryptographically verified due to potential > security issues otherwise. But they said those additional headers are only > relevant if if the IdP actually uses those values, and if not, they still > might need to look in the claims. > > What is the JOSE committee's stance on parsing the claims before signature > verification? > > Thank you kindly, > > Les > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
