RegMTS commented on issue #12495: URL: https://github.com/apache/apisix/issues/12495#issuecomment-3222970450
Hi @moonming, thank you so much for the quick and transparent response. It's very helpful to have confirmation that this is a current limitation of the plugin's architecture and not a misconfiguration on my end. To answer your questions directly: 1. **On external session storage:** While using an external store like Redis would certainly solve the immediate problem, I see it more as a solution for scalability and high availability. From my perspective, an ideal solution would allow APISIX to manage and share this context natively between routes, without the architectural dependency on an external component for a baseline setup. This would keep the deployment simpler for many common use cases. 2. **On other approaches:** Actually, `bearer_only: false` is not a strict requirement for the backend route. An alternative pattern where only the frontend route (`/*`) handles the full OIDC flow is very interesting. The absolute key to this pattern, and the core of our requirement, is the **seamless refresh token scenario**. When the user's session on the frontend expires, the `openid-connect` plugin should transparently refresh the token. This newly refreshed session/token must then be made available to the backend route. This ensures that the user can continue to consume the backend APIs without any interruption or need to re-authenticate. Is there a recommended way within APISIX to achieve this "token forwarding" or context propagation? For example, could the `openid-connect` plugin on the frontend route automatically propagate the refreshed token to subsequent calls targeting the backend route, which could then be protected by a simpler mechanism like `jwt-auth`? Crucially, this JWT must contain the same **identity claims** found in the OIDC session cookie, as our backend services rely on this information to operate correctly. The critical link is ensuring the backend route benefits from the refresh cycle managed by the frontend route. I am very keen to contribute to this discussion as I believe this is a cornerstone use case for leveraging APISIX as a complete security gateway for web applications. Thanks again for your engagement on this. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
