Okta RBAC roles not being applied correctly in OAuth2 configuration

[ivraju]

Issue submitter TODO list

• I've looked up my issue in FAQ
• I've searched for an already existing issues here
• I've tried running main-labeled docker image and the issue still persists there
• I'm running a supported version of the application which is listed here

Describe the bug (actual behavior)

We are encountering an issue where Okta-based RBAC roles are not being recognized or applied as expected within the Kafka UI (Kafbat) OAuth2 configuration. Despite a valid OAuth2 setup and successful authentication via Okta, the assigned user groups are not mapping correctly to the configured RBAC roles in the application.

The configuration is managed through Terraform and YAML application configuration, as shown below

yamlApplicationConfig:
  auth:
    type: OAUTH2
    oauth2:
      client:
        okta:
          clientId: "${local.okta_client_id}"
          clientSecret: "${local.okta_client_secret}"
          scope:
            - "openid"
            - "profile"
            - "email"
          client-name: "Okta"
          provider: "okta"
          redirect-uri: "${local.okta_redirect_uri}"
          authorization-grant-type: "authorization_code"
          user-name-attribute: "sub"
          issuer-uri: "${local.okta_issuer_uri}"
          jwk-set-uri: "${local.okta_jwk_set_uri}"
          custom-params:
            type: "oauth"
            roles-field: "Groups3"

  server:
    forward-headers-strategy: native
    servlet:
      session:
        cookie:
          secure: true

  rbac:
    roles:
      - name: "kafbat-read-role"
        clusters:
          - "${local.dev_msk_cluster_name}"
          - "${local.stg_msk_cluster_name}"
        subjects:
          - provider: oauth
            type: role
            value: aws_sso_devops
        permissions:
          - resource: clusterconfig
            actions: [ "view" ]
          - resource: topic
            value: ".*"
            actions:
              - VIEW
              - MESSAGES_READ
              - ANALYSIS_VIEW
          - resource: consumer
            value: ".*"
            actions: [ view ]
          - resource: schema
            value: ".*"
            actions: [ view ]
          - resource: connect
            value: ".*"
            actions: [ view ]
          - resource: acl
            actions: [ view ]

Observed Behavior

• Login via Okta succeeds (user is authenticated).
• However, RBAC mapping does not occur — users appear without assigned roles.
• The roles-field parameter (Groups3) might not be resolving correctly from Okta claims.

Expected behavior

After successful OAuth2 authentication, Okta user group mappings (e.g., aws_sso_devops) should align with the RBAC configuration, automatically granting corresponding permissions (view, messages_read, etc.).

Your installation details

1. App version - 8b5494b
2. Helm chart version - v1.3.0

Steps to reproduce

1. Authenticate to the application using Okta OAuth2.
2. Inspect application logs and user role mapping.

Screenshots

Okta configuration:

Logs

No response

Additional context

No response

[github-actions[bot]]

Hi ivraju! 👋

Welcome, and thank you for opening your first issue in the repo!

Please wait for triaging by our maintainers.

As development is carried out in our spare time, you can support us by sponsoring our activities or even funding the development of specific issues.
Sponsorship link

If you plan to raise a PR for this issue, please take a look at our contributing guide.

[fallen-up]

don't see scope "groups" in your config

my working config:

yamlApplicationConfig:
  auth:
    type: OAUTH2
    oauth2:
      client:
        okta:
          clientId: "${local.okta_client_id}"
          clientSecret: "${local.okta_client_secret}"
          scope:
            - "openid"
            - "profile"
            - "email"
            - "groups"
          client-name: "Okta"
          provider: "okta"
          redirect-uri: "${local.okta_redirect_uri}"
          authorization-grant-type: "authorization_code"
          user-name-attribute: "email"
          issuer-uri: "${local.okta_issuer_uri}"
          jwk-set-uri: "${local.okta_jwk_set_uri}"
          custom-params:
            type: "oauth"
            roles-field: "groups"

[lytx-awsjenkinstfs]

@fallen-up appreciate you responding.

I did try to scope to groups and roles-field: "groups" previously. However when I do that my Okta SSO login breaks (as shown in the screenshot ).

yamlApplicationConfig:
  auth:
    type: OAUTH2
    oauth2:
      client:
        okta:
          clientId: "${local.okta_client_id}"
          clientSecret: "${local.okta_client_secret}"
          scope:
            - "openid"
            - "profile"
            - "email"
            - "groups"
          client-name: "Okta"
          provider: "okta"
          redirect-uri: "${local.okta_redirect_uri}"
          authorization-grant-type: "authorization_code"
          user-name-attribute: "email"
          issuer-uri: "${local.okta_issuer_uri}"
          jwk-set-uri: "${local.okta_jwk_set_uri}"
          custom-params:
            type: "oauth"
            roles-field: "groups"

Also since we have other configs with name groups already we used Groups3 as the claim name. When I scope it to Groups3 I got the same result.

yamlApplicationConfig:
  auth:
    type: OAUTH2
    oauth2:
      client:
        okta:
          clientId: "${local.okta_client_id}"
          clientSecret: "${local.okta_client_secret}"
          scope:
            - "openid"
            - "profile"
            - "email"
            - "Groups3"
          client-name: "Okta"
          provider: "okta"
          redirect-uri: "${local.okta_redirect_uri}"
          authorization-grant-type: "authorization_code"
          user-name-attribute: "email"
          issuer-uri: "${local.okta_issuer_uri}"
          jwk-set-uri: "${local.okta_jwk_set_uri}"
          custom-params:
            type: "oauth"
            roles-field: "Groups3"

[Haarolean]

Can't really help here as we don't have/use okta, but I'm 99% confident it's a configuration issue (either in okta or the app settings). There are multiple successful cases with okta working fine reported occasionally, both here and on our Discord.

To further debug the mysterious "Invalid credentials" do this:

• Set logging.level.org.springframework.security config/env property with value TRACE
• Restart
• Upon authentication check logs, most likely AuthenticationWebFilter, there should be a clue on what's wrong. It's missing from the browser due to security decisions in spring framework.

[ivraju]

@Haarolean Thanks for the quick response. It turned out to be an issue with the Okta settings, and it’s resolved now. Thanks

[Haarolean]

@ivraju please give back to the community by posting what was your issue and the steps to solve it