Re: [w3c/ServiceWorker] How to handle redirected URL for login authentication offline. (#1226)

> How is it made?

I'm not the OP, there are multiple ways, and I can only guess. Let's imagine a SPA on https://example.com . Usually, if users click on Login, they will be redirected to Keycloak ( https://keycloak-server-connect ). Then they login, get HttpOnly cookie, and redirected back to the SPA with an authorization code. This authentication code is exchanged for access and refresh tokens through https://keycloak-server-connect/protocol/openid-connect/token endpoint with XHR or fetch. After that, SPA installs an [iframe](https://github.com/keycloak/keycloak/blob/main/services/src/main/resources/org/keycloak/protocol/oidc/endpoints/login-status-iframe.html) and checks periodically with XHR/fetch the state of the session from the https://keycloak-server-connect/protocol/openid-connect/login-status-iframe.html/init endpoint, which in turn returns 204 with a session state cookie.

On refresh, iirc, SPA checks the state again and compare it with local state, which doesn't match because SPA lost it (not a bug, it is intended). After that SPA redirects to keycloak, which returns a new authorization code (without re-authentication - user is already known because of HttpOnly cookie from keycloak), which can be exchanged for access/request token.

If I understand correctly, the question is about this session state check from the iframe to keycloak origin. I didn't tested that, but, probably, SW can't intercept the request to another origin. (And I think it shouldn't be enough with an unmodified keycloak-js adapter, because it will still make a redirect to keycloak.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1226#issuecomment-1403826286
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1226/1403826286@github.com>