It might be worth looking at Keycloak's JS client adapter to see how they handle some of these things: https://www.keycloak.org/docs/latest/securing_apps/index.html#_javascript_adapter <https://www.keycloak.org/docs/latest/securing_apps/index.html#_javascript_adapter>
> On Jul 8, 2020, at 4:55 PM, Isuru Ranawaka <[email protected]> wrote: > > We need to finalize methods to store access token, refresh token and Id > token. As Shivam , anuj suggested can use local storage, cookies or API > Gateway approach. Any ideas on > - How to handle silent refresh for invalidated tokens The Keycloak adapter has an updateToken() function that refreshes only if needed and returns a promise in which you're guaranteed a valid token. https://www.keycloak.org/docs/latest/securing_apps/index.html#updatetoken-minvalidity <https://www.keycloak.org/docs/latest/securing_apps/index.html#updatetoken-minvalidity> > - Synchronizing logouts for multiple tabs See the Session Status iframe: https://www.keycloak.org/docs/latest/securing_apps/index.html#session-status-iframe <https://www.keycloak.org/docs/latest/securing_apps/index.html#session-status-iframe> >>> > I guess httpOnly cookie is added from the server-side. But that won't be > feasible with the current approach. Custos provides access tokens in the > body, and not capable of handling cookies. I guess we can achieve this via > intermediate proxy. any thoughts? Is this a grpc-web limitation? Also, I'm guessing you'll need a proxy or something to read the access token out of the cookie on the server-side.
smime.p7s
Description: S/MIME cryptographic signature
