Add support for refresh tokens

[marshallswain]

We currently allow getting a new token by posting a valid auth token to <loginEndpoint>/refresh. Refresh tokens have a slightly different workflow as explained here: https://auth0.com/learn/refresh-tokens

[sarkistlt]

@bwgjoseph I would suggest to use regular express session, and store all tokens there, instead of client side. That's what I do and works perfectly fine with all types of apps including SPA

[bwgjoseph]

@sarkistlt You mean to say to store all client JWT token on server-side? Any reference/article material for that? I'm not exactly sure how the process would be like. So what does client sent, when they request for data (CRUD)?

[sarkistlt]

@bwgjoseph same as always, cookie, just add middlewere before registerring your services:

app.use('* | [or specific rout]', session(sess), (req, res, next) => {
      req.feathers.session = req.session || {};
      next();
    });

then in your server, for let's say customer login service, when customer is authenticated, you just store token in the session like ctx.params.session.token = token, where token is your JWT access or refresh token, depends on your application logic. And with any new request from client you will check if token exist in the session and will use it for authentication. This is much safer and secure approach, since none of the tokens are exposed on the client side at all.

I'll just add that this works best for client (browser) - server applications. When communicating internally between servers, or worker/server, you don't need session.

[daffl]

This has been discussed a lot before (I also added an entry to the FAQ) and it is not necessarily more secure to store a token in a session. If someone gets access to your page to be able to execute scripts they have also hijacked the session and can make authenticated requests anyway.

Hence it is usually ok to store a token in e.g. localStorage (which only the current page has access to as well) and it also works seamlessly with other non-browser platforms (like native mobile apps, server-to-server etc.) and websockets (I can't stress enough how painful it is to make websockets work seamlessly and securely with HTTP cookies - my life has been a lot easier since we stopped trying to do so). In general, a refresh token should be revokable though since it is usually a lot more long lived.

Either way, a pull request for this would be very welcome, I find it makes ironing out the details a lot easier.

[TheSinding]

@jackywxd - Great job, took a brief look at it and it seems like some great additions. Is there anyway of making it easier for the developer implementing this? Like integrating the hooks you've created into the library, so we wouldn't need to add the hooks later ?

I think you should create a pull request and we could have the discussion there.

[sarkistlt]

@daffl yes agree, especially with WS. And if both client and backend build by you or your team, yes it's best to just use JWT and avoid extra dependancies and complexity in your application. But in some cases, for example when building storefront REST-API that will be used by 3rd party companies / developers, it's easier to use regular session, and ask developers to include credentials with their requests then to describe how to retrieve access (and refresh) tokens, store it, and pass it with each requests. Which handled perfectly by feathers client, but in most cases when developer is not familiar with how backend built, they will use request, superagent, fetch or axios to connect their application to the backend. At least in my case this was the main reason to move storefront part of API to work with regular sessions instead of JWT directly.

[TheSinding]

But wouldn't that be the design decision and responsibility, of the maker of said storefront, to implement into their own API and then properly document this feature, instead of "forcing" this decision onto the community ?

[sarkistlt]

@TheSinding I think we can say 'forcing' about less commonly used approach, not about cookie which have been (and still is) most commonly used approach to manage user sessions.

And yes it is a design decision made after developers feedback that have been using the API. When you are running multi-tenant system or API that used by multiple teams, sometime best is to follow general industry practice to avoid additional confusion and extra time spent by developers, especially if alternative solution doesn't provide any advantage for end user.

Again to be clear, using JWT is great, and way easier to utilize especially for real time API and that's what we are using in 90% of cases + you don't need to run redis or something else to manage cookie sessions. But there some exceptional cases where it may not be the best chose, I brought example of that situation in my previous comment.

[TheSinding]

I wasn't saying you were wrong, I was just thinking "out loud" :)

IMO, I think the approach with JWT would be a better approach, since that is what is already supported and as @daffl it's also easier to work with

[jackywxd]

Thanks for all your feedback! JWT vs session is a different topic we can discuss separately.

I think one thing we all agree is that access token + refresh token is a much more secure solution than merely access token. It has been widely adopted by major Internet giants. It is fair to say the Feathers community would love to see Feathers main code base to provide built-in support for refresh token. Actually it surprised me when I first realized that Feathers doesn't support refresh token.

I have been using AWS cognito in couple of my projects, AWS Amplify will save three tokens in localStorage: ID token, access token and refresh token, Amplify handles all the dirty-works related to token management, and provides couple APIs that enables easy and straight forward interface working with Cognito backend. I would like to see similar development experience with Feathers.

[jackywxd]

@TheSinding Thanks for your previous great work!

Because existing authentication is implemented as normal service, we could easily enable refresh-token support by extending the class and adding couple hooks:

this.hooks({ after: { create: [issueRefreshToken(), connection('login'), event('login')], remove: [logoutUser(), connection('logout'), event('logout')], patch: [refreshAccessToken()], },

Just like we turn on Authentication by using the CLI, we could offer the similar option in CLI for refresh-token support. developer can simply answer YES, the CLI then automatically creating a customer "refresh-tokens" service and update refresh-token related configurations in default config file. So it is like a turn-key solution for developers.

[jackywxd]

@daffl David, thanks for creating Feathers! just wondering is there any "contributing guid", "coding guideline", "style guide" for Feathers?

[daffl]

As I mentioned before, a PR with the implementation for refresh tokens (or even just some ideas) would be very welcome. I didn't get a chance yet to check out the linked repos and this discussion is getting quite long. Having it all up to date and in one place would make things a lot easier. Some important bullet points:

• Refresh tokens can be issued by extending the Authentication Service
• Refresh tokens should be stored in localStorage
• Refresh tokens need to be revokable (so there needs to be a more general purpose implementation of the revocation mechanism described in https://docs.feathersjs.com/cookbook/authentication/revoke-jwt.html)
• Because of the additional complexity and setup (like Redis for storing revoked tokens) it can be available as a feature but shouldn't be enabled by default (i.e a standard generated app - can be part of the CLI but before doing anything on that, I'm still really looking for help in starting a hygen based generator)
• Contributing info can be found in the contributors guide

[matiaslopezd]

If someone is using refreshToken, we create a library that handles in frontend, accessToken and refreshToken like "sessions", too easy to use.

Only need to pass the tokens and the library tries to obtain a new acessToken with refreshToken when will expire. Currently is used in Videsk.

Repository: Front Auth Handler

[J3m5]

I saw this video about the risks related to JWT andrefresh tokens in SPA, it is really informative. https://pragmaticwebsecurity.com/talks/xssoauth.html