Removing refresh tokens

[pilcrowonpaper]

v0.12.0 released! - #149

Hi!

Recently, v0.10.0 was rolled out, and we've transitioned over to session based authentication. From what I've seen, the transition has been relatively smooth. With that, however, some existing concepts and APIs no longer fit the current implementation, and it seems some changes are needed. Refresh token is one of them.

Refresh tokens are useful when implementing JWTs. JWTs are short lived to minimize the attack window, so it needs something that is long lived that can be cross-checked with a database. Refresh tokens can also improve security if they are only sent for refresh requests (unlike access tokens that are sent for every requests), though Lucia was sending both tokens at every request. There is nothing gained from using a separate token for refreshing sessions right now. That's not to say having session short lived isn't important. They should expire if the user hasn't used them for a set amount of time.

The change

The solution here is to use access tokens as refresh tokens, ie, auto refresh. This means access token are short lived, but their lifetime are prolonged whenever they are used. This seems to be how NextAuth does it. But this is inefficient, and I'd think it's better if a new access token is issued on refresh. What we can do is have 2 expiration times for access tokens, one for the role as an access token, and another for the role as a refresh token. This means when an access token expires, that token can be used for some window of time to create a new access token, after which the original access token is deemed invalid.

Will it break stuff?

Yes. This change will likely force all old sessions to be invalid, and APIs will change for refreshing sessions. But, like v0.10.0, you will not lose any user data.

Will there be any more changes?

Yes. I don't think there will be another architectural change (auth wise), but APIs will likely evolve with user feedback and SvelteKit is still pre-1.0.