Request — Refresh token

[Aurelsicoko]

This issue has been opened because we (as the core team) are looking for contributors to help us co-develop the feature.

Link to the roadmap

Motivations

The current implementation doesn't offer the ability to refresh an existing valid token. Thus, it forces the user to log in every month to generate a new JWT token.

Tasks

1. Find a contributor
2. Define the needs
3. Discuss a solution and technical implementation
4. Ask for design
5. Submit RFC

Risks

• Security breach
• Required a better authentication flow (see [WIP] Add refresh token support to Auth flow strapi#2704)

[derrickmehaffy]

@Aurelsicoko I think this should just be apart of the change from Grant/Purest to passport. See: strapi/strapi#1819

There are numerous options for refresh tokens in passport.js. The endgoal here should be to ditch grant/purest and move to a provider model like the upload plugin for auth providers.

[adriatic]

Let me suggest to rephrase Derrick's statement this should just be a part of the change from Grant/Purest to passport:

• Identity Management (Authentication and Authorization) implementation should follow the approach taken to abstract Databases. In order to do that we need to decide what functionality from the industry leaders (Google Identity. AWS IAM, Auth0 and OKTA)

My suggestion is to add my list of providers to passport

Obviously this suggestion is a lot more ambitious than adding the support for token refreshment (@Aurelsicoko), so, take it with a grain of salt (read: I have no idea about company's plan for Identity Management support.)

[Aurelsicoko]

We do want to support more providers, especially for the companies and users asking for SSO support. I'm not sure to clearly understand; are we doing something by using Passport, then use the providers or develop our own to easily handle the authentication for any Identity Management system?

The only thing is that we cannot force the users to use one instead of another. The list cannot be exhaustive, we need to offer a lot of flexibility. We could install 3 or 5 providers by default (the most used ones) and then write guides in the documentation to easily explain how to develop a custom provider.

[adriatic]

@Aurelsicoko I fully support and appreciate the attitude you stated as:

The only thing is that we cannot force the users to use one instead of another. The list cannot be exhaustive, we need to offer a lot of flexibility. We could install 3 or 5 providers by default (the most used ones) and then write guides in the documentation to easily explain how to develop a custom provider.

Let me summarize my iterative discussion with @derrickmehaffy - where I wanted to point out that Strapi offering Identity Management support via passport.js might be insufficiently ambitious. Note that I used the conditional phase (might be) to indicate that I am not aware of Strapi's ambitions, so I am just trying to ensure that you do not lock yourselves in the narrow Identity Management domain covered by passport.js.

I am very interested in Identity Management since leading the development of a large healthcare application funded by Washington State and Microsoft, some 10 years ago. In that process, I learned about the importance of Marketing in this context. Many "big players" will not commit to using a solution that would limit them in their choice of Identity Management platform.

[derrickmehaffy]

@Aurelsicoko me and @adriatic had a long convo on slack, but I did clarify to him that directly adding a proprietary identify management into Strapi core most likely wasn't going to happen and that the plan was to use passport as basically a connection layer to those services.

@adriatic The short and simple to Strapi's passport plans is very simple. We are passing the users off to some service (be that facebook, github, auth0, whatever) and having them auth there. Once that auth is completed a token is passed back to Strapi which it then uses to pull whatever required information is needed (username, email) and that data is stored. After that we simply return the users info from strapi to them to be able to do authenticated requests using the JWT or whatever.

Beyond that there is no other plans to integrated identity management stuff like IAM permissions or the like, it's just basic user auth.

[adriatic]

Despite living 40 years in USA, my English based communications are not nearly sufficient to explain my comments on Strapi plans for Identity Management to @derrickmehaffy. I am seriously worried that my brain went south, because we are dealing with a simple situation.

So, Derrick, please try again to understand that you did not understand me. I am not suggesting to directly add a proprietary identity management into Strapi core. I AM suggesting design the Strapi authentication service USING THE ABSTRACT MODEL that could be “subclassed” to any of the Auth0, AWS IAM, etc.

It is my opinion that future customers from Fortune 500 group would consider identity management based on passports inadequate.

Note that Derrick is aiming to ensure simplicity for today’s Strapi customers, where I worry about reluctance from “big players” to use Strapi because a toy like identity management.

Now having Aurelien in this discussion, I will happily stop bugging you all with this proposal, If Aurelien can tell me that passportjs based authentication/authorization is sufficient for Strapi 🤐