How can I extend session expiry?

[byte-my-briefs]

Brief Question

I would like to extend the session expiry ("exp"). Currently, it seems to be set to 60 seconds. For reasons explained at more length in the next section, I would like to extend it rather significantly.

The session docs claim that the "exp" field is "[d]etermined using the Token lifetime JWT template setting in the Clerk Dashboard.". However, I modified this up to 604,800 (1 week) to test it yesterday and it has had no effect.

Does anyone know how I can address this?

Detailed Summary of Issue

NOTE: The above is a workaround fix for the issue I am experiencing below. The below is more complex, and I welcome any advice that helps to address the issue more directly.

I have a (1) Webapp, and (2) a Chrome extension (primarily run as a "New Tab"), both coded in Sveltekit. I would like to share session state between the two. This works, so long as the webapp is open in a separate tab. However, after the webapp is closed, the session within the extension expires with 60 seconds. Though the frontend session is still recognize (and the <SignedIn /> component therefore still functions properly), the backend rejects all requests, claiming that the session token ahs expired.

I have tried adapting the @clerk/chrome-extension to work with SvelteKit, but it has resulted in no success. Additionally, it is worth noting that I have followed the steps outlined in the @clerk/chrome-extension README, including disabling URL-based session sharing in dev/staging and adding the extension to allowed_origins.

I am not sure if I am settings my settings wrong or otherwise handling the session-sharing wrong.

Please let me know if you have any advice, or if any more information would in evaluating the issue.

[aglontaru-sapiema]

Did you find any way of extending the "exp"? I also need to do this to allow my web app users to authenticate within a CLI.

[byte-my-briefs]

Not particularly. To fix my issue instead, I run the following function on an interval:

setTimeout(async () => {
        // Get a new, updated session cookie.
        const token = await clerk.session.getToken(...);

        // Update the cookie on my webapp for use by my extension.
        await chrome.cookies.set({
                httpOnly: false,
	        name: '__session',
	        path: '/',
	        secure: false,
	        url: import.meta.env.VITE_WEBAPP_URL,
	        value: token
        });
}, 30_000); // Run every 30s to ensure webapp cookie never goes stale

This exact approach will (of course) not work in a CLI because you do not have access to chrome API. However, perhaps there is a similar way you can use the Clerk client to fetch a new session token and manually update the cookie?

Happy to help brainstorm ideas and answer any questions, so please let me know!

[andrewshvv]

@ByteMyBriefs Hey! Can you please share a bit more on how to properly do that in Chrome Extension? For some reason my clerk.session is either null, or if I am using clerk.load() it complains about no document (seems like expected to be run in content script)

1. Is this script part of content script or background script? (background)
2. Can you show how you setup Clerk instance is that normal setup or with some things like in chrome-extension package?

I have exactly the same situation as you do. I have Clerk on my website, but need to keep JWT refreshed in my Chrome Extension to access backend api.

[andrewshvv]

Link on related discussion in Clerk discord

[jescalan]

https://github.com/orgs/clerk/discussions/3829

[thedogwiththedataonit]

I think I found the solution. The docs aren't too clear on this, but you have to create a JWT template to define a custom expiration. Once created, the getToken() function has a parameter called template which is where you put the name of the JWT template you created.

const token = await getToken({ template: "Admin", })

I just spent 2 hours trying to figure this out so I hope it helps someone.

[thedogwiththedataonit]

Just want to add a couple notes here!

• If you need to extend the lifetime of the __session JWT, this is in fact the way to do it.
• It's worth noting however that this is an antipattern that we advise against doing, as this will result in a weaker security posture for your application.
• The session lifetime and expiration of the session JWT are two different things entirely. The session JWT expires every minute, but you aren't logged out when it expires, it is refreshed automatically in the background by Clerk.
• If you feel that you have a use case for your application that requires extending the session JWT expiration, I'd strongly recommend reaching out to Clerk support by emailing [email protected], detailing your use case, and asking for a consult. In 99% of cases, there is a way you can make it work without compromising your app's security, and we can talk you through it.

Hi Jeff! Thank you for your insight here.

I am fairly new to Clerk so I am trying to wrap my head around how to best implement it. Would you suggest calling getToken() for every API call made from the client? I am currently storing it client side with the extended expiration, but if there is a better more secure approach here, I'd love to know! Thanks!

[jescalan]

Hey there! Appreciate the followup for sure. If your api is on the same origin (and subdomain) as your frontend, the token will be sent automatically with requests as a cookie. If you have set up your api on a separate domain or subdomain, all you need to do is make sure you are adding the token as a header to each request to your api. We have docs on how to do this right here, in case that's helpful!

[devransimsek]

Hi, Jeff!
What happens if we want to test our APIs on the Postman and we need user information? I think there should be a way to use for long time tokens at least on development.
@jescalan

[jescalan]

Generally, we recommend against trying to use longer time testing tokens, as JWTs cannot be revoked, so if you leak a long term token in any way, even if it's an accident, there's nothing you can do to stop whoever has the token from being able to fully take over that user's account short of rotating the instance keys and signing out all your users.

If you really feel strongly about this and are willing to accept the risks, you can create a custom JWT template and use this instead of the default session JWT in Clerk's dashboard. Otherwise, the best approach might be just to make sure that you hit the /tokens endpoint to get a fresh token before sending other test requests.

[shellscape]

@jescalan while that makes sense for production, it makes absolutely zero sense for the development tenant. there is no inherent risk to a development environment aside from a user treating it as production, and that is certainly not on Clerk. I'm a backend developer, and I don't dabble in the frontend. Using the API to constantly get refreshed tokens is unnecessarily burdensome for the use case, and Clerk is actively choosing to make DX worse for anyone not a frontend dev with that choice. If I want to say, test new endpoints using GraphiQL, I have to run a script constantly and typically before each request to the API, between server restarts, etc and I have to make sure that I copy the damn thing from output and paste it into an interface fast enough to execute a query before the thing expires.

I'm absolutely amazed that no one there has considered this scenario.