Recommended way to use the access token in the client.

[brahma-dev]

Hi,
What would be the recommended way to get the access token on the client side, once the user has logged in ?

[Dan6erbond]

This functionality was addressed in #37. The session is accessible to the user on the client-side. So, you can wrap your own session using the access_token passed by the provider with the profile() callback if you're using the default OAuth2Provider, and then, pass that on to your client-side session with the session() callback.

You may also store refresh tokens in the SKA token as explained in #28 to later rotate access tokens. For that use the profile() callback in your provider and return the tokens along with the profile, and then if necessary refresh the access token using the refresh token in the jwt() callback:

export const appAuth = new SvelteKitAuth({
  providers: [
    new GoogleOAuthProvider({
      clientId: import.meta.env.VITE_GOOGLE_OAUTH_CLIENT_ID,
      clientSecret: import.meta.env.VITE_GOOGLE_OAUTH_CLIENT_SECRET,
      profile(profile, tokens) {
        // include tokens and a provider ID in the profile, which is then stored in token.user by SKA
        return { ...profile, ...tokens, provider: "google" }; 
      },
    }),
  ],
  callbacks: {
    session (token, session) {
      if (token.user) {
        // avoid exposing refresh tokens to the client for security purposes
        const { refresh_token, ...user } = token.user;
        return { user };
      }
    },
    jwt (token, profile) {
      if (token.accessTokenExpired) {
        // refresh access token
        token = { ...token, access_token: newAccessToken };
      }
      return token;
    },
  },
});

This flow adds all the security measures and stability to sessions you will need. In SvelteKitAuth the user first logs in, which is handled through the providers, and the base OAuth2Provider allows you to transform the data returned using the profile() callback. Which by default is only the user profile without the tokens.

After the profile has been returned, SKA will store that in token.user by default, which can be overriden with the jwt() callback, and the session is handled similarly, as standard it simply returns the user, but can contain additional or less information.

One possible issue might be with short-lived access tokens from your auth provider, that they will expire while your client is still browsing the application. For that there is currently no solution, so you will have to manually run a fetch on /api/auth/session and then update the session store like so:

fetch("/api/auth/session").then(session.set);

This will force your jwt() callback to run again, so that session() gets access to the parsed SKA token, and ensure that your access tokens are refreshed.

[brahma-dev]

Thanks. I had figured the same, but was concerned if I may be accidentally leaking data.

Is token.accessTokenExpired something sk-auth calculates ? I don't remember seeing it in the token object.

[Dan6erbond]

Ah, no. That's just for illustration purposes, you'd have to implement some kind of expiresAt (if it isn't included by your provider) and check it on each run to renew the access token.