Offline Support

[mjoellnier]

I really hope that the bug template is the correct choice as I'm not sure if it really is a bug... but I'll give it a shot:

Describe the bug

I'm currently working on a react based (PWA) application which utilizes keycloak for authentication and authorization. I'm tring to implement offline capabilities with the help of a workbox powered service worker (with the configuration as specified below). I'm also succesfully issuing offline tokens to the client and the online request to the realm URL is cached sucesfully:

To Reproduce

I configured the default created (CRA) service worker as:

registerRoute(
  ({ url }) => url.hostname.includes("secure-xxxxxxxxxxxxxx.de"),
  new NetworkFirst({
    cacheName: "xxxxxxxxxxxxxxx",
    plugins: [new ExpirationPlugin({ maxAgeSeconds: 3600 })], // TODO adjust duration for prod
  })
);

also I configured the Keycloak login scope to issue offline tokens:

keycloak.login({ scope: "offline_access" })

When visiting the on the dev server deployed app you can see the service worker registering and caching the request to the auth/realms/{...}/account API. As soon as I'm switching to offline and reloading the page everything works fine until keycloak tries to open the URL https://secure-xxxxxxxxxxxxxx.de/auth/realms/xxxxxxxxxxxxxx/protocol/openid-connect/login-status-iframe.html/init?client_id=client&origin=xxxxxxxxxxxxxx which seems to be issued by the login-status-iframe.html.

I guess that this call leads to the Keycloak instance not properly initiated which means that the Loading component which I defined in the ReactKeycloakProvider does not close -> the app is not usable in offline mode.

Expected behavior

I'd expect that the issued offline token and precached API calls should be enough for the ReactKeycloakProvider to initiate itself and to use my application offline.

Screenshots

Check that offline tokens were issued:

Desktop (please complete the following information):

Tested on (but I guess it's platform independend):

• OS: macOS 11.6
• Browser Chrome, FireFox
• Version 100.0, 99.0

Smartphone (please complete the following information):

• Device: Google Pixel 6
• OS: Android 12
• Browser Chrome
• Version 100

[Bessonov]

@mjoellnier did you found any solution?

I think there are many issues coming together. Take it with a grain of salt, because I can be wrong.

The main difference between offline token and session is in the way how they are stored. Offline tokens are stored in the database and sessions are stored in the infinispan. Another difference is the expiration of tokens. Offline token should work even the sessions used for login is expired.

For a mobile application with a direct grant there is no difference in both, except if you have "never expire if refresh token is used correctly"-requirement. Infinispan implementation is broken for this use case because of SSO Session Max, but offline tokens works fine.

For a spa web client, I didn't found any way to support "never expire"-scenario neither with offline tokens nor with a session. I just get logged out. The only advice I got from a keycloak expert was to handle refresh through a proxy. Probably, you ran in the same issue.

I think your pointer to the login-status-iframe.html/init is correct. I didn't check it closely, but the endpoint uses KeycloakSession. Therefore, I assume that even you use an offline token, this endpoint returns 403 on session expiration after some hours. Probably, this is the correct behavior when we take into account that offline tokens aren't intended for web clients, because the usage of refresh token should enlarge the session (which is broken with infinispan like mentioned above).

Because you use service workers, you can try faking 204 response. This should tell your client that session is OK.

On the other side, I don't think caching will help you much. It feels wrong. And I'm not sure that keycloak-js (the original keycloak web client used by this library) supports this scenario. Probably, in the best case you will be responsible for managing expiration events by yourself. And in the worst case you will need another oauth2 client.