OIDC authentication issue after upgrade to ELK 8.19.12 + ROR 1.69.1

Hello,

I’m running into an issue with OIDC authentication after upgrading my stack and would appreciate any guidance.

Current setup (working previously):

  • ELK & Kibana: 8.6

  • ReadonlyREST (ROR): 1.67

  • OIDC authentication working as expected

Upgraded setup (problematic):

  • ELK & Kibana: 8.19.12

  • ROR: 1.69.1

After the upgrade, I’m no longer able to authenticate via OIDC in Kibana.

Relevant Kibana logs:

[2026-04-21T15:33:13.970+00:00][debug][plugins][ReadonlyREST][oidcRouterFactory] Obtained raw profile: {"sub":"abcd1234"}
[2026-04-21T15:33:13.970+00:00][debug][plugins][ReadonlyREST][oidcController] Obtained user name from profile: abcd1234
[2026-04-21T15:33:13.970+00:00][debug][plugins][ReadonlyREST][oidcController] Obtained groups from profile:
[2026-04-21T15:33:13.970+00:00][debug][plugins][ReadonlyREST][oidcController] Created JWT for ROR with claims: {"user":"abcd1234","groups":[],"assertion":{"sub":"abcd1234"},"x-ror-origin":"oidc_kc"}

Observations:

  • The sub claim is correctly retrieved (abcd1234, which is my identifier).

  • Username is correctly extracted.

  • However, groups are empty, which seems to be causing authorization/authentication failure.

  • JWT is created but contains "groups":[].

  • I am not using authorization groups with my IdP

  • I am using ECK

  • I am able to authenticate using basic auth

Questions:

  1. Has there been any change in how ROR 1.69.1 handles OIDC group extraction compared to 1.67?

  2. Do I need to explicitly configure a groups claim mapping in the newer version?

  3. Could this be related to a change in default claim names or required settings in Kibana/Elasticsearch 8.19?

  4. Are there any additional debug steps I should take to verify what is being returned by the IdP?

Here is my ROR config:

readonlyrest:
  prompt_for_basic_auth: false
  access_control_rules:
  - name: "Kibana Service Account"
    token_authentication:
      token: "Bearer ${KIBANA_SERVICE_ACCOUNT_TOKEN}"
      username: "service_account"
  - name: "ELASTIC-INTERNAL"
    auth_key: "elastic-internal:${INTERNAL_USR_PASS}"
  - name: "ELASTIC INTERNAL PROBE"
    type: "allow"
    auth_key: "elastic-internal-probe:${INTERNAL_PROBE_PASS}"
  - name: "Full Admin Kibana"
    groups: ["full-admin"]
    indices: ["*"]
    kibana_access: "admin"
  - name: "Full Admin Users"
    groups: ["full-admin"]
    indices: ["*"]
    actions: ["*"]
  - name: "Client Admin Group Kibana"
    groups: ["client_admin"]
    indices: ["kibana_client_admin", "*"]
    kibana_access: "rw"
    kibana_index: "kibana_client_admin"
  - name: "Client Admin Group 0"
    groups: ["client_admin"]
    indices: ["*"]
    actions: ["*"]
  users:
  - username: "fulladmin"
    groups: ["full-admin"]
    auth_key_sha256: "<auth_key_string"
  - username: "abcd1234"
    groups: ["client_admin"]
    ror_kbn_auth:
      name: "kbn1"

  ror_kbn:
  - name: "kbn1"
    signature_key: "<string_containing_my_signature_key"

Hello @Diana, we will try to reproduce it on our side and let you know what’s going on.

Hello @Diana

[2026-04-21T15:33:13.970+00:00][debug][plugins][ReadonlyREST][oidcRouterFactory] Obtained raw profile: {“sub”:“abcd1234”}

Looks like the OIDC provider doesn’t send all data via /userInfo the method. Is it a change that the provider was also updated?

Can you change userInfoSource method in your kibana.yml OIDC provider settings? Usually id_token should contain all user data; if not, please try access_token.

Hello,

I tested using all options available for userInfoSource, the error seems similar:

  • without userInfoSource parameter

[2026-04-23T11:37:32.774+00:00][debug][plugins][ReadonlyREST][oidcRouterFactory] Obtained raw profile: {"sub":"abcd1234"}
[2026-04-23T11:37:32.775+00:00][debug][plugins][ReadonlyREST][oidcController] Obtained user name from profile: abcd1234
[2026-04-23T11:37:32.775+00:00][debug][plugins][ReadonlyREST][oidcController] Obtained groups from profile:
[2026-04-23T11:37:32.775+00:00][debug][plugins][ReadonlyREST][oidcController] Created JWT for ROR with claims: {"user":"abcd1234","groups":[],"assertion":{"sub":"abcd1234"},"x-ror-origin":"oidc_kc"}
[2026-04-23T11:37:32.892+00:00][debug][plugins][ReadonlyREST][legacyRenderer] Fetching frontend dependency: /usr/share/kibana/plugins/readonlyrestkbn/proxy/preKibanaProxy/auth/../../../node_modules/jquery/dist/jquery.min.js
[2026-04-23T11:37:33.027+00:00][debug][plugins][ReadonlyREST][authController][x-ror-correlation-id=d51f8cef-f09d-4c06-a13e-cb502f1b3d69] login request rejected: username: abcd1234
[2026-04-23T11:37:33.027+00:00][info][plugins][ReadonlyREST][authController][x-ror-correlation-id=d51f8cef-f09d-4c06-a13e-cb502f1b3d69] Could not login in: Forbidden by ReadonlyREST
[2026-04-23T11:37:33.028+00:00][debug][plugins][ReadonlyREST][identitySessionHeadersValidation][x-ror-correlation-id=d51f8cef-f09d-4c06-a13e-cb502f1b3d69] There is no user request identity. Token revalidation aborted

  • with userInfoSource: ‘id_token‘
[2026-04-23T11:25:35.262+00:00][debug][plugins][ReadonlyREST][oidcRouterFactory] Obtained raw profile from id_token { iss: 'https://auth.test.oidc', iat: 1776943535, exp: 1776947135, sid: '69FwhYR6HDUxtdaUZBYp/69zMA6poHAxbIb4YXk8SHg', acr: 'loa-4', aud: [ 'rp-di-test123456' ], sub: 'abcd1234', at_hash: '_PUtdKt9jTN9GATiP6w7dg', azp: 'rp-di-test123456', auth_time: 1776928538 }
[2026-04-23T11:25:35.262+00:00][debug][plugins][ReadonlyREST][oidcController] Obtained user name from profile: abcd1234
[2026-04-23T11:25:35.263+00:00][debug][plugins][ReadonlyREST][oidcController] Obtained groups from profile:
[2026-04-23T11:25:35.263+00:00][debug][plugins][ReadonlyREST][oidcController] Created JWT for ROR with claims: {"user":"abcd1234","groups":[],"assertion":{"iss":"https://auth.test.oidc","iat":1776943535,"exp":1776947135,"sid":"69FwhYR6HDUxtdaUZBYp/69zMA6poHAxbIb4YXk8SHg","acr":"loa-4","aud":["rp-di-test123456"],"sub":"abcd1234","at_hash":"_PUtdKt9jTN9GATiP6w7dg","azp":"rp-di-test123456","auth_time":1776928538},"x-ror-origin":"oidc_kc"}
[2026-04-23T11:25:35.676+00:00][debug][plugins][ReadonlyREST][authController][x-ror-correlation-id=6fee3a41-02ed-41f4-b127-efea047601c5] login request rejected: username: abcd1234
[2026-04-23T11:25:35.676+00:00][info][plugins][ReadonlyREST][authController][x-ror-correlation-id=6fee3a41-02ed-41f4-b127-efea047601c5] Could not login in: Forbidden by ReadonlyREST
[2026-04-23T11:25:35.678+00:00][debug][plugins][ReadonlyREST][identitySessionHeadersValidation][x-ror-correlation-id=6fee3a41-02ed-41f4-b127-efea047601c5] There is no user request identity. Token revalidation aborted
  • with userInfoSource: ‘access_token‘ and removing groupsParameter: ‘groups’

[2026-04-23T11:40:14.363+00:00][debug][plugins][ReadonlyREST][oidcRouterFactory] Obtained raw profile from access_token { sub: ‘abcd1234’, scope: ‘openid email prjtpms:p3znx2cp:admin p3znx2cp:test’, jti: ‘42e0d3815c3c56da14ff61e698a54e9a’, iss: ‘https://auth.test.oidc’, sid: ‘69FwhYR6HDUxtdaUZBYp/69zMA6poHAxbIb4YXk8SHg’, aud: [ ‘rp-di-test123456’ ], client_id: ‘rp-di-test123456’, exp: 1776948013, iat: 1776944413 }
[2026-04-23T11:40:14.363+00:00][debug][plugins][ReadonlyREST][oidcController] Obtained user name from profile: abcd1234
[2026-04-23T11:40:14.363+00:00][debug][plugins][ReadonlyREST][oidcController] Obtained groups from profile:
[2026-04-23T11:40:14.363+00:00][debug][plugins][ReadonlyREST][oidcController] Created JWT for ROR with claims: {“user”:“abcd1234”,“groups”:,“assertion”:{“sub”:“abcd1234”,“scope”:“openid email prjtpms:p3znx2cp:admin p3znx2cp:test”,“jti”:“42e0d3815c3c56da14ff61e698a54e9a”,“iss”:“https://auth.test.oidc”,“sid”:“69FwhYR6HDUxtdaUZBYp/69zMA6poHAxbIb4YXk8SHg”,“aud”:[“rp-di-test123456”],“client_id”:“rp-di-test123456”,“exp”:1776948013,“iat”:1776944413},“x-ror-origin”:“oidc_kc”}
[2026-04-23T11:40:14.474+00:00][debug][plugins][ReadonlyREST][legacyRenderer] Fetching frontend dependency: /usr/share/kibana/plugins/readonlyrestkbn/proxy/preKibanaProxy/auth/../../../node_modules/jquery/dist/jquery.min.js
[2026-04-23T11:40:14.778+00:00][debug][plugins][ReadonlyREST][authController][x-ror-correlation-id=016a5cc1-6562-4cf5-8e40-937f6a494d93] login request rejected: username: abcd1234
[2026-04-23T11:40:14.778+00:00][info][plugins][ReadonlyREST][authController][x-ror-correlation-id=016a5cc1-6562-4cf5-8e40-937f6a494d93] Could not login in: Forbidden by ReadonlyREST
[2026-04-23T11:40:14.779+00:00][debug][plugins][ReadonlyREST][identitySessionHeadersValidation][x-ror-correlation-id=016a5cc1-6562-4cf5-8e40-937f6a494d93] There is no user request identity. Token revalidation aborted

Also, this is the OIDC config inside kibana.yml:

readonlyrest_kbn:
    auth:
        oidc_kc:
            authorizationURL: https://auth.test.oidc/oauth2/authorize
            buttonName: OIDC Auth
            clientID: rp-di-test123456
            clientSecret: <client_secret_string>
            issuer: https://auth.test.oidc
            jwksURL: https://auth.test.oidc/oauth2/jwks
            kibanaExternalHost: test123456-kb.c1.di-test.example
            logoutUrl: https://test123456-kb.c1.di-test.example/logout
            protocol: https
            scope: openid email
            tokenEndpointAuthMethod: client_secret_post
            tokenURL: https://auth.test.oidc/oauth2/token
            type: oidc
            userInfoSource: access_token
            userInfoURL: https://auth.test.oidc/oauth2/userinfo
            usernameParameter: sub
        signature_key: <signature_key_string>

Hello @Diana

The scope part looks suspicious

scope: openid email

Could you change it to

scope: 'openid profile roles email'

?

yes, i changed, the issue is still there. take also into account that my initial config was working fine with ELK 8.6.2 and ROR 1.67.

It’s strange because there wasn’t a change around OIDC, between 1.67.2 and 1.69.0. Based on logs, I can only say that, for some reason, the OIDC provider doesn’t send information about roles/groups.

  1. What IdP and version do you use?
  2. Could you confirm that you run the exact IdP provider version and that it was configured exactly the same way when you tested it with ROR 1.67?

we are using an internal IdP based on keycloak but i don’t have a lot of information about it.
i confirm that we use the same IdP configured exactly the same. but, i double checked the ROR version used and it’s 1.60.

Ok, it was few changes with OIDC, with a library to handle it included, so something could change here. Let’s try to ask the provider for an access token directly, so we will be sure that it’s related to the OIDC library we use internally in the ReadonlyREST KBN plugin. There is a chance that the previous library version added some scope values internally, which is why it worked before. Could you perform a curl request via

curl -X POST https://auth.test.oidc/oauth2/token \
  -d "grant_type=password" \
  -d "client_id=rp-di-test123456" \
  -d "client_secret=<client_secret_string>" \
  -d "username=<user>" \
  -d "password=<pass>" \
  -d "scope=openid email" 

You should receive a JSON with an access_token. Paste the access_token into https://www.jwt.io and send the result, please.

i am not allowed by my IdP to use the password grant flow with my personal account. however, the decode of the JWT can be found in the logs above. do you need more details?

@Diana, because in your JWT there are no groups/roles, it means you should use the ror_kbn_authentication rule, not the ror_kbn_auth rule.

  - username: "abcd1234"
    groups: ["client_admin"]
    ror_kbn_authentication:
      name: "kbn1"

We identified and fixed this problem/inconsistency in ROR 1.67.x.

Please let us know if it helped.

this fixed the issue. thanks a lot!

2 Likes