🇧🇪Belgium @filsterjisah

Could you provide more details, please? The attached patch and the issue description do not seem to align. The patch translates the ALTCHA keys instead of incorporating the Translation Configuration module (which is part of the core). However, the issue description states that 'text' is not being translated.

Patch re-rolled against 3.0.x branch.

Alright, I'll keep the 'client ID' session addition request in the other issue so that this one can be merged.

I agree with keeping MRs small in size. The point I want to emphasize is that the OpenID Connect session needs client context: in theory, you can have multiple clients active & connecting to the same Drupal account—for example, when using combinations of social clients like Facebook and Google.

To implement anything generic inside the OpenID Connect module with these stored tokens, we need the context of their origin. That’s the main reason I suggested including that addition in this issue. That said, I agree that this context isn’t really needed when using only one client and working with code within a custom module.

I’d love to hear your opinion on this.

To refresh the token, it is essential to have access to the OpenID client used to obtain the initial tokens, as it must also be utilized for refreshing them. I would suggest also storing the client id in the OpenID Connect session.

e.g. https://git.drupalcode.org/project/openid_connect/-/merge_requests/131/d...

MR looks greats! Lets merge this?

I believe this is a very good idea.

Currently, I’m exploring a method to automatically refresh expired access tokens when a valid refresh token is still available. Ideally, this feature should include a configuration option to enable or disable the auto-refresh behavior.

To proceed, we first need these two issues to be merged:
- https://www.drupal.org/project/openid_connect/issues/2923419 ✨ Method to use the refresh token Needs review
- https://www.drupal.org/project/openid_connect/issues/3327440 💬 Store and Use Refresh Token on Expiry Active

Approach 1:
- Use an event listener that listens to either KernelEvents::REQUEST or AccountEvents::SET_USER.
- Check the session for the OpenID session's expire timestamp. If the token is near expiration and a valid refresh token is available, invoke the ->refreshTokens() method and replace the session tokens with the refreshed values.
Implement a locking mechanism to prevent multiple requests from using the same refresh token simultaneously, as it can only be used once.
- If refreshing the tokens with the stored refresh token fails, log the user out and return a "419 Page Expired" response.
- If no valid refresh token is available, log the user out and return a "419 Page Expired" response.

Approach 2:
- Use hook_cron() to identify access tokens that are about to expire and handle them in batches.
- Instead of continuously refreshing tokens in the background, consider using the session timestamp combined with the session's maximum lifetime. However, this could be problematic if the maximum session lifetime is set to a higher value.

I believe the first approach is the better option.

filsterjisah → created an issue.