bzp2010 commented on issue #12495: URL: https://github.com/apache/apisix/issues/12495#issuecomment-3223143029
@RegMTS @moonming recommends using Redis for session sharing, but the reason is not complete: If you use the same `session.secret` on multiple routes, session sharing will be possible, but you must explicitly configure it; otherwise, APISIX will generate and populate it. By default, you are using cookie-based sessions, where session data is encrypted with the secret and sent to the client as a cookie. Since the client does not know the secret, it cannot decrypt or modify it, making it secure. In this case, the data is not stored or persisted by any central component. Although APISIX can delete cookies from the browser, you cannot revoke a session because malicious actors can recover the session by recording and manually reconfiguring the cookie. Despite this, it is still secure, just a minor drawback of this stateless scheme. It is similar to the situation we encounter when using JWT. Additionally, since the cookie is sent with every HTTP request header, it may become quite large, potentially wasting your server bandwidth and triggering request header limits on your reverse proxy chain. For example, as far as I know, Nginx has such a default limit, which may result in a 400 “too large request header or cookie” error. A viable alternative is to use APISIX shdict to store session data and only send the session ID cookie to the client. This keeps the data on the server, and the client can never access it, so even if your secret is compromised, it remains secure. However, shdict cannot be efficiently propagated across multiple APISIX instances, which poses an obstacle to deploying an APISIX cluster. Therefore, Redis is listed as a compromise solution. It ensures that session data is retained solely on the server while reducing request headers, and it also enables seamless data sharing across multiple APISIX instances. This is the issue you encountered when setting `bearer_only` to false. --- Another completely different approach is to set `bearer_only` to true. In this case, APISIX will no longer use sessions or redirect clients to the IDP. Instead, it will **ONLY** verify the access token in the client API call. If the verification passes, the request will be forwarded to the upstream server. Otherwise, a 401 status will be returned to the client. Your "client" fully controls the authentication process. Let's take a web app as an example. Your web app is deployed on a CDN, and traffic to the web page does not pass through APISIX. When a user first opens the page, your page explicitly knows that no user credentials (access token) are stored in the browser, so you need to display a prompt informing the user that they need to log in. After the user clicks the button to redirect to the IDP and completes the entire authentication process (e.g., via the OIDC implicit flow), your web app will obtain the access token. Subsequently, the web app needs to request the API to retrieve the user's data. At this point, the request will pass through APISIX, which only needs to attach the access token. APISIX can then verify the credential, extract the user's identity, and pass it on to the upstream service. When the credentials in the browser expire, if the user accesses the application again, the browser will attach an invalid access token to access APISIX, and you will receive a 401 response. At this point, simply prompt the user to log in again, and they will be able to access the application once more. Additionally, since web apps can also obtain a refresh token, they can refresh the access token while the refresh token is still valid, even if the access token has expired. Users are unaware of token expiration and refresh, so they do not experience any interruptions. In this mode, APISIX will no longer be responsible for any tasks related to login and session/token issuance. Your application will handle these tasks independently, starting from obtaining and storing the access token. Since it is only verification, there is no need for server-side persistence, and Redis is not required. This helps create a seamless user experience. When a user clicks “Log In” on your page, they will be redirected to the IDP to complete the login process, after which the application can be used. When `bearer_only` is set to false, it is primarily used to add authentication to existing applications that you cannot modify. When users access the application, if there is no session data in the cookie, APISIX will redirect them directly to the IDP for login. Users will see a brief white screen before being redirected directly to the login page, rather than seeing your brand information followed by a brief, reasonable interaction before being properly redirected to the IDP. -- 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]
