# OIDC Login Problem

**URL:** <https://discuss.elastic.co/t/oidc-login-problem/371063>\
**Category:** Elasticsearch\
**Tags:** elastic-stack-security\
**Created:** [November 26, 2024, 6:24am UTC](https://discuss.elastic.co/t/oidc-login-problem/371063 "2024-11-26T06:24:19Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![cafuego](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/cafuego/32/25146_2.png) [@cafuego](https://discuss.elastic.co/u/cafuego)\
**Post date:** [November 26, 2024, 6:24am UTC](https://discuss.elastic.co/t/oidc-login-problem/371063/1 "2024-11-26T06:24:19Z")

</div>

After updating from 8.15.3 to 8.16.1 today, we found we were unable to login to Kibana via our SSO server. Instead we got the message "We hit an authentication error".

After a bunch of digging, I eventually found an error in the logs on one of our nodes:

```auto
"Authentication to realm oidc1 failed - Failed to authenticate user with OpenID Connect (Caused by org.elasticsearch.ElasticsearchSecurityException: Failed to retrieve remote JWK set.; Caused by java.text.ParseException: Invalid JWK at position 0: Unexpected type of JSON object member with key exp)"

```

Editing the jwk handler to remove the `exp` field from the keys objects in the JSON did indeed resolve our login problem.

I guess an oidc library got updated in the newer release and I missed it in the release notes.

Adding it here, so if someone else runs into the same issue they now have the fix. Assuming they control the OIDC server side output.

---

<div class="post-metadata">

**Author:** ![slobodanadamovic](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/slobodanadamovic/32/106791_2.png) [@slobodanadamovic](https://discuss.elastic.co/u/slobodanadamovic)\
**Post date:** [November 27, 2024, 8:38pm UTC](https://discuss.elastic.co/t/oidc-login-problem/371063/2 "2024-11-27T20:38:33Z")

</div>

@cafuego Could you share an example of a JWK which caused the parse error?

The Nimbus OIDC SDK dependency has been [upgraded in 8.16.0](https://github.com/elastic/elasticsearch/pull/108799) and I suspect that the change in the SDK to use gson may have caused this. I'm suspecting that `exp` parsing failed due to an either `null` or invalid type (e.g. string instead of number).

---

<div class="post-metadata">

**Author:** ![cafuego](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/cafuego/32/25146_2.png) [@cafuego](https://discuss.elastic.co/u/cafuego)\
**Post date:** [November 28, 2024, 1:21am UTC](https://discuss.elastic.co/t/oidc-login-problem/371063/3 "2024-11-28T01:21:55Z")

</div>

@slobodanadamovic Yes, here is a truncated version:

```auto
{
  "keys": [
    {
      "e": "AQAB",
      "n": "m13CI5aQt8F9yo8GEjxhGg9B...",
      "mod": "m13CI5aQt8F9yo8...",
      "exp": "AQAB",
      "x5c": [
        "MIIC+jCCAeKgA..."
      ],
      "kty": "RSA",
      "use": "sig",
      "alg": "RS256",
      "kid": "8N_Uyn8By94Lb0dDCD..."
    }
  ]
}

```

So `exp` is definitely a string. Just outright dropping it from the JSON fixed the issue; I had a quick look at an OKTA jwk blob and they didn't have an `exp` either. Doing that seems to have not broken anything.

A bit more searching shows that it's an optional boolean, not a string, so my current plan is to upstream modify the Drupal module that generated this JWK. It simply copies the `e` value to `exp` and that's clearly wrong.

---

<div class="post-metadata">

**Author:** ![slobodanadamovic](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/slobodanadamovic/32/106791_2.png) [@slobodanadamovic](https://discuss.elastic.co/u/slobodanadamovic)\
**Post date:** [November 28, 2024, 10:19am UTC](https://discuss.elastic.co/t/oidc-login-problem/371063/4 "2024-11-28T10:19:23Z")

</div>

> [@cafuego](#):
>
> So `exp` is definitely a string. Just outright dropping it from the JSON fixed the issue; I had a quick look at an OKTA jwk blob and they didn't have an `exp` either. Doing that seems to have not broken anything.
> 
> A bit more searching shows that it's an optional boolean, not a string, so my current plan is to upstream modify the Drupal module that generated this JWK. It simply copies the `e` value to `exp` and that's clearly wrong.

Thanks for providing the example. The `exp` field is [optional expiry time of RSA keys](https://connect2id.com/products/nimbus-jose-jwt/examples/jwk-exp-nbf-iat). It's quite easy to mix `e` and `exp` fields.

The value must be an integer (not boolean) which represents a number of seconds since the Unix epoch. The upgraded SDK library is now being stricter while parsing JWKS JSONs.