[BUG] Unable to login via OpenID when refresh_tokens=true and MS ADFS as Idp provider with a very long refresh_token

[IT-AlexKor]

What is the bug?
Unable to login when OpenID and refresh_tokens=true - login just cycled (too many redirects when only openid selected and multiple_auth = false). Possible reason - too long refresh_token (from openid) breaks security_authentication cookie.

Workaround: refresh_tokens=false

Possible solution (just my opinion, you know better): store refreshToken in ExtraAuthStorage (like other tokens).

How can one reproduce the bug?
Not sure that it can be reproduced on ADFS installation.

Common steps:

• Enable OpenId auth method and connect dashboard to MS ADFS 2016+ via OpenID
• Enable refresh_tokens=true
• Try to login - should be looped (too many redirects)

Maybe easier to reproduce during local development in IDE.

I check OpenSearch Data server with token - it's working with ID Token via rest api, the problem is only on OpenSearch Security Dashboards Plugin.

See Additional context.

What is the expected behavior?
Successful login when OpenID and refresh_tokens=true (with long refresh_token), token refreshing should work too.

What is your host/environment?

• Ubuntu 24
• OpenSearch Dashboard 3.2.0
• OpenSearch Security Dashboards Plugin 3.2.0.0 (from package.json)
• ADFS on Windows 2016

Do you have any screenshots?
Nope

Do you have any additional context?
First of all, I'm not a frontend-developer, so somewhere I can be inaccurate.

Response from (truncated):
{
"access_token": "<998 symbols JWT token>",
"token_type": "bearer",
"expires_in": 7200,
"resource": "urn:microsoft:userinfo",
"refresh_token": "<3042 symbols Refresh token>"
"refresh_token_expires_in": 29674,
"id_token": "<947 symbols ID token>"
}

some details from ID token:

• user_name: <23 symbols>
• backend_roles: <25 items>

During local node debug I found possible bug place:

security-dashboards-plugin/server/auth/types/openid/routes.ts

Line 205 in 36fe977

if (this.config.openid?.refresh_tokens && tokenResponse.refreshToken) {

if (this.config.openid?.refresh_tokens && tokenResponse.refreshToken) {
Object.assign(sessionStorage.credentials, {
refresh_token: tokenResponse.refreshToken,
});
}

Extra auth cookies security_authentication_oidcX was successfully set.

If refreshToken=true then refreshToken from response will be set inside sessionStorage, which stored (as I understand) in security_authentication cookie. After that security_authentication will be too long (longer than 4096 bytes, at least 4473 bytes) and will be rejected by browser. At the next request auth will be broken, because security_authentication wasn't set (rejected by browser from previous response).

When refreshToken=false the security_authentication cookie is successfully set and work - auth work too.

opensearch_dashboards.yml:
server.host: '0.0.0.0'
server.port: 443
server.customResponseHeaders : { "Access-Control-Allow-Credentials" : "true" }
server.ssl.enabled: true
server.ssl.certificate: local-ssl.pem
server.ssl.key: local-ssl.key
opensearch.hosts: [https://127.0.0.1:9200]
opensearch.ssl.verificationMode: none
opensearch.username: kibana
opensearch.password: 213123123123
opensearch.requestHeadersWhitelist: [Authorization, securitytenant, security_tenant]
opensearch_security.multitenancy.enabled: true
opensearch_security.multitenancy.tenants.preferred: [Private, Global]
opensearch_security.readonly_mode.roles: [kibana_read_only]
opensearch_security.cookie.secure: true
opensearch.ssl.certificateAuthorities: [ "root_ca.crt" ]
opensearch_security.auth.multiple_auth_enabled: true
opensearch_security.auth.type: ["openid","basicauth"]
opensearch_security.openid.base_redirect_url: https://127.0.0.1
opensearch_security.openid.connect_url: <adfs_url>
opensearch_security.openid.client_id: <client_id>
opensearch_security.openid.client_secret: <client_secret>
opensearch_security.openid.trust_dynamic_headers: true
opensearch_security.openid.verify_hostnames: false
opensearch_security.openid.extra_storage.cookie_prefix: sec_auth_oidc
opensearch_security.openid.extra_storage.additional_cookies: 5
opensearch_security.openid.refresh_tokens: true
opensearch.logQueries: true
logging.verbose: true

[cwperks]

[Triage] @IT-AlexKor Thank you for reporting this issue. I have not seen a similar report for 3.2 and there haven't been many changes in this area from prior versions. Did you start experiencing this issue on upgrade or is this a new cluster?

I have seen refresh issue before where there were too many roles, but I don't think that's going on here. Another thing I would like to check if the date claims in the token to rule out any clock skew issues.

[IT-AlexKor]

Hi @cwperks

It's a new cluster with the latest app version.

Perhaps this problem is related to the current environment. Possibly some settings in ADFS makes the Refresh Token too long (I'm not sure, not used MS ADFS before). This is probably why you may not have heard about this problem before, because not everyone may have this configuration with ADFS and such settings (in ADFS).

But I'm sure at 99.99% that the problem is in the Refresh Token length:

• I connected to local Node server (via --inspect cli argument and chrome://inspect) and saw that Refresh Token contains 3042 symbols, when access_token is 998 symbols and id_token is 947 symbols. So it means that I successfully exchange "auth code" to tokens

  security-dashboards-plugin/server/auth/types/openid/routes.ts

  Line 207 in 36fe977

  refresh_token: tokenResponse.refreshToken,

• After that I saw in Chrome Dev Tools that security_authentication cookie was rejected by browser - it was too long (4473 bytes of 4096 max cookie length)
• I was successfully made few requests to OpenSearch Data Server via curl with "Authorization: Bearer <id token>" header (200/204 response). So the token/time/etc is working as expected.
• After I disable refresh_tokens policy (refresh_tokens=false) OpenSearch Dashboard started working (and working right now, but without automatic token refresh). And only this block was disabled with this option (it's a possible logical root cause)

  security-dashboards-plugin/server/auth/types/openid/routes.ts

  Line 205 in 36fe977

  if (this.config.openid?.refresh_tokens && tokenResponse.refreshToken) {

Because of security policy, I can't show you the real response from the Idp token endpoint, but it looks like:
{
"access_token": "<998 symbols JWT token>",
"token_type": "bearer",
"expires_in": 7200,
"resource": "urn:microsoft:userinfo",
"refresh_token": "<3042 symbols Refresh token>"
"refresh_token_expires_in": 29674,
"id_token": "<947 symbols ID token>"
}

In local debug environment you can get any valid response and replace RefreshToken with some 3042 symbols string (be sure refresh_tokens=true). After that you will reproduce the problem.

Anyway I think that we didn't break anything if we move Refresh Token to split-cookie (as other tokens before).