OAuth2 session is not revalidated

[tasso94]

Environment (Required on creation)

Camunda Run with OAuth2.

Description (Required on creation; please attach any relevant screenshots, stacktraces, log files, etc. to the ticket)

When logging out from Cognito:

https://camunda-run.auth.us-east-1.amazoncognito.com/logout?response_type=code&client_id=$CLIENT_ID&scope=openid&redirect_uri=http://localhost:8080/

Replace $CLIENT_ID with what you can find in spring.security.oauth2.client.registration.

... the user is still logged in to the web apps.

Steps to reproduce (Required on creation)

• Login to web apps using Cognito login form.
• Logout from Cognito using the logout URL above.
• Navigate through the webapps.

Observed Behavior (Required on creation)

User is still logged in.

Expected behavior (Required on creation)

User should be logged out.

Root Cause (Required on prioritization)

Not clear. I guess the authentication is cached forever. Maybe we need to implement something like https://github.com/camunda/camunda-bpm-platform/issues/3146 here as well.

Solution Ideas

1. Implement something similar to #3146.
2. Configure session cookie max age 5 minutes (might be problematic when running multiple webapps within one Spring Boot application or when the user changes it again).
3. Maybe there is some Spring Security built-in mechanism to solve this which ensures the authentications are revalidated periodically.

Hints

It only works when logging out from Cognito first and using the OAuth2 Spring Security Logout URL second: http://localhost:8080/logout

Like this, the session cookie is cleared.

However, this is not acceptable because it requires another User action. When the identity provider forces a logout or removes the user, Camunda should check regularly if the user is still valid.

Links

Breakdown

### Pull Requests
- [ ] https://github.com/camunda/camunda-bpm-platform/pull/4603

Dev2QA handover

• [x] Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment

[danielkelemen]

Notes

OAuth2 works with tokens for authentication and Spring Security is fully supporting this. Tokens have a lifetime until they are valid, this is the exp claim, for instance: exp=2024-09-09T16:13:05Z. This lifetime is configurable in the identity providers, including the usage of refresh tokens. Cognito & OKTA default is 1h.

General security recommendation is to use short-lived access tokens combined with long-lived refresh tokens. With refresh tokens applications can renew access tokens but they can be revoked and the refresh mechanism won't work when the user is not logged in anymore in SSO.

Articles:

• https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/
• https://docs.spring.io/spring-security/reference/servlet/oauth2/client/authorization-grants.html#oauth2Client-refresh-token-grant

OIDC Back Channel Logout

Details

OpenID Connect Session Management 1.0 allows the ability to log out the end user at the Client by having the Provider make an API call to the Client. This is referred to as - Spring Security feature: https://github.com/spring-projects/spring-security/issues/7845 - Spring Security docs: https://docs.spring.io/spring-security/reference/reactive/oauth2/login/logout.html#configure-provider-initiated-oidc-logout

Outcome:

• Unfortunately, this doesn't seem to be supported in Okta: https://devforum.okta.com/t/okta-back-channel-initiated-logout/22000.
• We can still enable the feature in our auto config.
  • Added it in the logout ticket: https://github.com/camunda/camunda-bpm-platform/issues/4455

Spring Security & Okta Configurations

• Okta id_token lifetime is fixed for 1 hour: https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/#token-lifetime
  • Refresh and Access token lifetimes can be changed but it doesn't seem to influence Spring Security.
  • The token stored in SecurityContext and in Session are different. Spring logs the security context token which is the id_token with 1h lifespan. See tokens issued at iat=2024-09-13T11:34:21Z Session contains the access token with 5mins lifespan:

    SecurityContext: 2024-09-13T12:34:21Z
    HttpSession: 2024-09-13T11:39:21.859091Z

• Spring Security's session can be configured via server.servlet.session.timeout: 10m and this will invalidate the session but only after inactivity. Once the session is expired a new token would be reissued.
• In AWS Cognito all lifetimes are configurable, I set all of them to 5 minutes and refresh-token to a few days. In the logs it looks like Spring Security keeps using the expired token.

Resources:

• Spring Security expired & refresh token handling.
  • Blog post - This guide uses similar setup and implements a custom ExpiredTokenFilter to handle this problem. The filter uses Spring classes so it's fairly straight forward.
  • Stackoverflow - From 2018 but complains about similar problem. Suggestion was also a custom filter to check token validity.

Outcome:

• Problem - Expired & refresh token
  • Added an AuthorizeTokenFilter filter that re-authorizes the token if needed using the refresh_token grant.
• Problem - Revalidate token more often
  • Customers can configure revalidation with a short-lived access token. I think that's a sufficient solution.
  • OAuth2AuthorizedClientRepository defines where and how to store tokens. Default implementations is HttpSessionOAuth2AuthorizedClientRepository. This could be extended similarly than our cache time to live.
• Decision: Use the AuthorizeTokenFilter and rely only on the provider settings for token lifetime.

[danielkelemen]

Dev2QA

Make sure no expired access token is used in the application. Our filter logs the expiration, you can activate debug log in application.yaml with:

logging:
  level:
    org.camunda.bpm.spring.boot.starter.security.oauth2: DEBUG

Notes:

• Okta access token lives for 5 minutes. This is the minimum but it can be changed in Okta. (See Confluence)
  • Our application will not try to revalidate before the access token expiry! This means you need to wait 5 minutes.
• Okta refresh token can be enabled with offline_access in application.yaml scopes.
  • You can tell if refresh token was used with an expired token by either the logs or the browser network history:
  • Without refresh token:
    • In the logs you should see Authorize failed: could not re-authorize expired access token.
    • In the browser network there will be an Okta redirect.
• User can be invalidated in Okta (see Confluence). Okta self logout is also fine.
  • In the logs an Authorize failed: ... error will appear.
• Congito self logout doesn't seem to invalidate tokens. Disabling the user does the trick.

[gbetances089]

Verified on camunda-bpm-run-ee-7.22.0-20240919.175253-98