ermites-io / oidc Goto Github PK

as title says, comment for more docs & links will follow

Because of all the tenants and the various hacks of microsoft, OpenID connect needs some tweaks as to match proper issuers, reported by @mestrade on implementing oidc with Azure validation errors ends up with this:

invalid iss: https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0 vs issuer: https://login.microsoftonline.com/{tenantid}/v2.0

also ID tokens claims includes microsoft specific fields : tid which can be used, check @mestrade PR #2 for details of the problem.

References:

• https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc
• https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens

In:

The code using "alg" in the jwk parsing is disabled. The alg is determined with the len of the "n" modulus found in the jwk.

Using the modulus len with Google/Microsoft/Github oauth/oidc endpoints is working well.

Gitlab is actually providing "alg" as "RS256" but the provided "n" modulus len is 512, which cause rsa.Verify to fail.
By using the "alg" value, the verification is done correctly.

RSA private key representation
gitlab keys from oidc configuration url

We are using AEAD inside this library, should we implement a key commitment scheme?
keys are pseudo-random (KDF, so I lean toward a KISS: no), the validation endpoint might act as an oracle in a potential key partionning attack against the cookie, let's verify and make sure it does not happen.
Key commitment could just remove that risk.

References:

• https://eprint.iacr.org/2020/1153.pdf

• pretty obvious.

JWT issuer, audience and expiration verification happens ONLY after JWT sig validation.

IMHO there is no need to engage heavy crypto operations if JWT issuer, audience and expiration are not valid.

WDYT?

as title says.