Better handle expired token

[xtuc]

I'm using the Android app with an Mastodon implementation that use expirable user tokens, I believe the official Mastodon server can be configured to expire tokens too.

For instance, when I try to edit my profile from the app, I see in the server's logs:

GET /api/v1/accounts/verify_credentials 401
Error: JWT has expired.

and the app shows an error: https://user-images.githubusercontent.com/1493671/215757542-862302eb-f43b-4bea-91e8-99330b96073f.jpeg without trying to recover. The only way is to manually logout and login again for a new token.

Note that the app is showing errors everywhere but /api/v1/accounts/verify_credentials is best for demonstration.

The same issue is present on iOS but haven't opened an issue yet.

[grishka]

Mastodon implementation that use expirable user tokens

And it does that to solve what?

[xtuc]

@grishka It's good security practice to periodically rotate private keys and set expiry on tokens.

[grishka]

Again, what is the practical issue that the involvement of time in authentication would solve? "Good security practice" is something merely theoretical. In practice, if someone obtains a device where you're logged in, there are two options:

• You set a password (or biometric auth, whatever) on the OS level. They won't gain access to your account regardless of whether your sessions expire.
• There is no OS-level password. They'll gain access to your account regardless of whether your sessions expire, because I'm sure they don't expire in 15 minutes like they do in banks.

So, expiring sessions do nothing to protect anyone from anything — they're nothing but an annoyance. So are password expiration policies. Here are my thoughts on authentication involving time formulated more succinctly by a friend (in Russian).

[xtuc]

For more context, the user session tokens we are using are JWT and are signed. It's the signing key pair that is automically and periodically rotated, meaning that after a certain time the JWT can't be verified anymore. Leaking the private key is much worse than a user's JWT, it's good practice to proactively rotate them.

We set the expiry on JWT to have users request a new JWT signed with the new pair of keys. This isn't an annoyance to users as it can be handled behind the scenes. Our problem is that the Mastodon application doesn't allow to relogin once the JWT has expired.

I understand that Mastodon doesn't rely on signed JWT and might not run into this issue.

[grishka]

How do you imagine "relogin behind the scenes" working? The regular login flow involves opening a web browser in which the user enters their credentials and clicks "allow", and then gets redirected back to the app via a custom URL scheme. I'd assume that the browser session would also expire in your setup — so there won't be any way to do it without user interaction.

[xtuc]

"behind the scenes" was maybe a bit optimistic. Similar to the login flow, would it be possible to open a web browser, follow redirections and load cookies left during login? With some authentification provider that would allow to relogin without interaction from the user and worse case the user has to login again.