Support verification of HS256-signed JWTs #134
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
stanhu
force-pushed
the
sh-fix-hs256-jwt
branch
2 times, most recently
from
540aadc to
5dabd6f
Compare
stanhu
commented
Nov 21, 2022
stanhu
commented
Nov 24, 2022
stanhu
force-pushed
the
sh-fix-hs256-jwt
branch
from
5dabd6f to
bd05088
Compare
When an OpenID provider such as Keycloak is configured to use the
HS256 algorithm to sign JSON Web Tokens (JWTs), previously logins
would fail with an obscure error:
```
JSON::JWS::UnexpectedAlgorithm (no implicit conversion of OpenSSL::PKey::RSA into String)
```
The HS256 algorithm relies on a shared secret between the client and
the server, and this secret is not in the list of JSON Web Key Set
(JWKS) that is typically retrieved via a public endpoint during OpenID
Discovery.
The error was happening because decoding a HS256-signed JWT with
public key RSA key will fail. We should only attempt to decode with
the configured `client_options.secret`.
To do this, we need to decode the JWT to examine the header to
determine how it was signed. For example:
```json
{
"typ": "JWT",
"alg": "RS256",
"kid": "RrHQomcBaw2FJZ9Q5skkNaPC6sHJFLUAf4uoeaItDPE"
}
```
This indicates that the payload was signed with `RS256`, a public key
algorithm.
Once we know the algorithm used to decode, we can determine which key
to use. For public key algorithms such as `RS256`, we use the
JWKS. For signature-based algoriths such as `HS256`, we use the
configured client secret.
This merge request also cleans up some technical debt. Previously we
didn't peek at the unverified JWT to determine the key ID (`kid`) that
the payload was signed with. If we got a `KidNotFound` exception from
the decoding, previously we couldn't tell whether this was happening
because we didn't have a matching key in JWKS, or whether the JWT
didn't have a `kid` to begin with. Now that we decode the header, we
can tell these cases apart. If the JWT has no `kid` and we get
`KidNotFound` from decoding, we know the server didn't supply the
right set of keys. Otherwise, we can just use try key until we find
one that works.
Relates to
https://gitlab.com/gitlab-org/ruby/gems/gitlab-omniauth-openid-connect/-/issues/1
This is part of the effort to upstream changes in the GitLab fork:
https://gitlab.com/gitlab-org/ruby/gems/gitlab-omniauth-openid-connect/-/issues/5.
stanhu
force-pushed
the
sh-fix-hs256-jwt
branch
from
bd05088 to
57b0321
Compare
If a client is configured for a specific `client_signing_alg` but the JWT returns a different algorithm, fail the callback immediately to prevent some insecure downgrade from happening.
stanhu
force-pushed
the
sh-fix-hs256-jwt
branch
from
59ed6ce to
58f9761
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When an OpenID provider such as Keycloak is configured to use the
HS256 algorithm to sign JSON Web Tokens (JWTs), previously logins
would fail with an obscure error:
The HS256 algorithm relies on a shared secret between the client and
the server, and this secret is not in the list of JSON Web Key Set
(JWKS) that is typically retrieved via a public endpoint during OpenID
Discovery.
The error was happening because decoding a HS256-signed JWT with
public key RSA key will fail. We should only attempt to decode with
the configured
client_options.secret.To do this, we need to decode the JWT to examine the header to
determine how it was signed. For example:
{ "typ": "JWT", "alg": "RS256", "kid": "RrHQomcBaw2FJZ9Q5skkNaPC6sHJFLUAf4uoeaItDPE" }This indicates that the payload was signed with
RS256, a public keyalgorithm.
Once we know the algorithm used to decode, we can determine which key
to use. For public key algorithms such as
RS256, we use theJWKS. For signature-based algoriths such as
HS256, we use theconfigured client secret.
This merge request also cleans up some technical debt. Previously we
didn't peek at the unverified JWT to determine the key ID (
kid) thatthe payload was signed with. If we got a
KidNotFoundexception fromthe decoding, previously we couldn't tell whether this was happening
because we didn't have a matching key in JWKS, or whether the JWT
didn't have a
kidto begin with. Now that we decode the header, wecan tell these cases apart. If the JWT has no
kidand we getKidNotFoundfrom decoding, we know the server didn't supply theright set of keys. Otherwise, we can just use try key until we find
one that works.
Relates to
https://gitlab.com/gitlab-org/ruby/gems/gitlab-omniauth-openid-connect/-/issues/1
This is part of the effort to upstream changes in the GitLab fork:
https://gitlab.com/gitlab-org/ruby/gems/gitlab-omniauth-openid-connect/-/issues/5.