🚀 Feature: Configurable JWT expiration

[zwhy2024]

🔖 Feature description

Can I extend the expiry time of jwt? How should I do this?

🎤 Pitch

in the development environment, I would like the token to expire for a longer period of time

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[stnguyen90]

At the moment, the JWT expiration time is not configurable. I'll leave this issue as a feature request to make the JWT expiration time configurable.

For now, you'd have to tweak the 3rd parameter here:

appwrite/app/controllers/api/account.php

Line 1298 in 6122a25

$jwt = new JWT(App::getEnv('_APP_OPENSSL_KEY_V1'), 'HS256', 900, 10); // Instantiate with key, algo, maxAge and leeway.

.

To tweak it, you can mount in a modified version of the account.php file.

[malikdoksoz]

Expiring JWT for mobile app will not be good for user experience. I think this setting should be added to the .env file.

[singhbhaskar]

Hey @stnguyen90 ,
Can I work on this?

[stnguyen90]

@singhbhaskar thanks for your interest! 🙏🏼 This one may require more planning so it won't be a good one for you to work on. Maybe after it's been planned out some more, we can reach out to the community to work on it.

[malikdoksoz]

@singhbhaskar thanks for your interest! 🙏🏼 This one may require more planning so it won't be a good one for you to work on. Maybe after it's been planned out some more, we can reach out to the community to work on it.

Does it really require a plan to add the configuration of this to the env file? I'm asking out of curiosity.

[stnguyen90]

Does it really require a plan to add the configuration of this to the env file? I'm asking out of curiosity.

Yes, because this is something that might actually make more sense to be a project-level configuration rather than global one. As such, we would need to think about how it should be configured via the Console and how it should be described and explained.

[zwhy2024]

I would like to be able to set the expiry time of jwt in the console

[BadgerBloke]

Hi @stnguyen90,

Yes as you said, it should be at project level not global level. We can put it inside Auth > Security in similar fashion of Session Length. If it makes sense then I would love to work on this.

However, JWT duration will be capped by Session Length. If assigned then I'll start working ASAP 🚀

Just a brief, I came here to open a request for this feature and found this already opened issue. So, I've good idea of actual requirement from user point of view.

[malikdoksoz]

Great feature for mobile app

[stnguyen90]

@BadgerBloke, thanks so much for raising your PRs! 🙏🏼 Let me talk to the team about this.

[stnguyen90]

@BadgerBloke, could you provide more insight into why you need this feature?

[BadgerBloke]

Sure @stnguyen90 , in my org, we have multiple projects so for a couple of projects 15 minutes is a bit high and at the same time for mobile application it is a bit low (from ux point of view) however, it is not a good idea to have very high JWT expiration only for avoiding the re-login rather we have to use refresh token for getting a fresh set of tokens without pushing the user for re-login. But, we don't have refresh token as of now.

I'm sure that there will be other scenarios when the user needs to change it.

Here, we are keeping the default JWT expiration time as 15 minutes only.

But in case someone has to change it then they will have the option.

---

Very very high level roadmap for SSO

💡I was about to put a proposal to have the capability to select the JWT signing algorithm. Currently we are using HS256 which is using a secret key only for signing as well as verification. But with algo like RS and ES we will have private/public key and in this case appwrite admin need not to share their private or signing key even then another backend will be able to validate the JWT without making any api call to appwrite.

💡We should also have the refresh token functionality.

💡 Option to include user data in JWT payload.

💡with above capability our Appwrite will be perfect fit for SSO.

---

Even if we agree and go for incorporating the above points then it will take some time and in that case we can take configurable JWT expiration as the first step towards SSO otherwise users will have at least this much capability.

Hope you find it making sense
Thanks

[stnguyen90]

@BadgerBloke you raised SSO as a use case...would you be able to use OAuth2 instead? With OAuth2, they only sign into the provider once and then they can allow any other app access. We released support for an OIDC provider which should be supported by big auth providers.

[BadgerBloke]

@stnguyen90 yeah I saw the OpenID Connect in our latest release and the same is available on cloud as well now. So, first of all congrats to the whole Appwrite team 🎉

I explored the options like Keycloak and there is no doubt that they are great but their documentation is not very friendly. I didn't get any other good open source project(s).

The best part about Appwrite is that, it is very easily understandable, The documentation is really cool, so if it has the above JWT capabilities then even without integrating other services it will be able to fulfill the SSO requirements.

But, it's ok if this doesn't align with Appwrite's vision.

[BadgerBloke]

However, if we go for these features then i would love to work on the same and get it done

[BadgerBloke]

Hi @stnguyen90 , since this issue was already opened by @3lur way earlier than i started participating and the same was in discussion too. So, if we do not go for features i mentioned above even then you can accept it provided this PR fulfills the requirements of this issue otherwise please let me and I'll do the needful.

Thanks

[stnguyen90]

@BadgerBloke,

But with algo like RS and ES we will have private/public key and in this case appwrite admin need not to share their private or signing key even then another backend will be able to validate the JWT without making any api call to appwrite.

You might want to 👍🏼 this issue for this request.

if it has the above JWT capabilities then even without integrating other services it will be able to fulfill the SSO requirements.

could you provide some more insight into how this can be used for SSO?

@malikdoksoz,

Great feature for mobile app

Would you also provide some insight into why this would be needed in mobile apps?

[malikdoksoz]

@stnguyen90

@malikdoksoz,

Great feature for mobile app

Would you also provide some insight into why this would be needed in mobile apps?

Imagine that in a mobile application, we typically don’t want the user’s session to expire after a certain period in most scenarios. In other words, I would like the session to remain active even if the user reopens the application after 10 days.

[BadgerBloke]

You might want to 👍🏼 this issue for this request.

@stnguyen90 thanks for mentioning this, I’ll consider this issue when start working.

could you provide some more insight into how this can be used for SSO?

I am realising that by simply saying the term SSO lead to some confusion. So, let rephrase the idea:

This SSO is not going to fulfil the requirements of signing in into services like zoom, slack, etc. because for that we have to support SAML and/or OpenID Connect to provide identity.

Here, we are going to provide the SSO solution for an organisation’s own multiple projects. Let me put it through an example -

An Organisation have multiple projects like Project 1, Project 2, Project 3, and SSO Project
Now assume that each project has their Application Server and Client App
So, when client makes a request to their Application Server and in absence of required sessions details Application Server will redirect to SSO app with callback params and on successful login SSO app will redirect back with the help of callback params.

this is very high level overview of the flow.

When we sign the JWT using any variant of ES or RS algo then Application Server doesn’t have to make an API call on every request to SSO Server i.e., Appwrite because public key or jwks can be cached after fetching [#1112] and JWT will get verified on Application Server itself.

In this way organisation has to maintain only one user base and they can put the project level access inside prefs (custom attribute field) or for more fine grained controls this logic can be maintained on the respective project level itself.

[barart]

+1 on this, i would like to manually set the expiration time of jwt tokens, in my case i have a native php project (and you cant create a session with the php sdk), so, my login page (simple html and js page with email and password) create the jwt token and store it as a cookie, then my php retrieve the cookie and allow access to user or not, 15 minutes is too low for my users and is annoying asking them to login again every 15minutes, i cant use oauth or other methods because is not a open system, i create the accounts (users cant register)