Skip to content
This repository has been archived by the owner on Jun 2, 2024. It is now read-only.

Gitlab master #39

Open
wants to merge 45 commits into
base: master
Choose a base branch
from
Open

Gitlab master #39

wants to merge 45 commits into from

Conversation

hhorikawa
Copy link
Member

stanhu and others added 30 commits April 23, 2021 17:14
Add .gitlab-ci.yml to test code

See merge request gitlab-org/gitlab-omniauth-openid-connect!1
When a key ID (`kid`) is not included in the JWT, that means we don't
know anything about which signing key to use. The json-jwt library
expects the `kid` value to be present if a JWK Set is presented.  If a
missing `kid` exception is raised, we now iterate through each key to
find one that works.

Closes omniauth/omniauth_openid_connect#64
A random value is created in each test case, so we don't
need to initialize this again.
Fix handling of JWT without key ID

See merge request gitlab-org/gitlab-omniauth-openid-connect!2
In non-standard OpenID Connect providers, such as Azure B2C, discovery
does not work because the discovery URL does not match the issuer field.
If a JWKS URI is provided when discovery is disabled, we should make an
HTTP request for the keys and use the response.

Closes omniauth/omniauth_openid_connect#72
Fetch key from JWKS URI if available

See merge request gitlab-org/gitlab-omniauth-openid-connect!3
Update README and CHANGELOG

See merge request gitlab-org/gitlab-omniauth-openid-connect!4
client_singing_alg could be passed in as a string, and we should make it
possible to specify either a string or symbol.
Always convert client_signing_alg to be a symbol

See merge request gitlab-org/gitlab-omniauth-openid-connect!5
`JSON::JWK::Set::KidNotFound` should never be raised because we are
checking individual keys within the set.
SImplify error handling for decoding individual keys

See merge request gitlab-org/gitlab-omniauth-openid-connect!6
Add email_verified field to info dict

See merge request gitlab-org/gitlab-omniauth-openid-connect!7
When an OpenID provider such as Keycloak is configured to use the HS256
algorithm to signed 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.
Support verification of HS256-signed JWTs

See merge request gitlab-org/gitlab-omniauth-openid-connect!8
Release v0.6.0

See merge request gitlab-org/gitlab-omniauth-openid-connect!9
Keycloak doesn't use the OAuth2 client secret to encrypt JWT secrets.
We need a separate secret to verify the JWT tokens.

This commit also cleans up some code and eliminates the need for using
`client_signing_alg`, since we peek at the JWT header to decide how to
decode the token.
Add option for specifying jwt_secret

See merge request gitlab-org/gitlab-omniauth-openid-connect!10
Release v0.7.0

See merge request gitlab-org/gitlab-omniauth-openid-connect!11
For binary secrets as used by Keycloak, we need to encode the secret in
base64.
stanhu and others added 15 commits July 16, 2021 20:36
Add base64-encoded jwt_secret option

See merge request gitlab-org/gitlab-omniauth-openid-connect!12
Release v0.8.0

See merge request gitlab-org/gitlab-omniauth-openid-connect!13
Fix jwt_secret documentation

See merge request gitlab-org/gitlab-omniauth-openid-connect!14
Adding CONTRIBUTING.md after license audit review

See merge request gitlab-org/gitlab-omniauth-openid-connect!16
add support for ES[256|384|512|256K] algos

See merge request gitlab-org/gitlab-omniauth-openid-connect!17
Release v0.9.0

See merge request gitlab-org/gitlab-omniauth-openid-connect!18
As described in nov/openid_connect#61,
`OpenIDConnect::ResponseObject::IdToken.decode` assumes public-key
encryption and does not make it possible to verify a token signed with a
HS256. The update to the gem to distinguish between RSA keys and HS256
keys created an issue where other public-key algorithms (e.g. ECSDA)
weren't recognized.  We simplify this code by using the private key only
when we detect an HMAC type.
Assume public key encryption unless HMAC is specified

See merge request gitlab-org/gitlab-omniauth-openid-connect!19
Release v0.9.1

See merge request gitlab-org/gitlab-omniauth-openid-connect!20
@hhorikawa hhorikawa self-assigned this Jan 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants