Access Tokens should have expiration date

[pkreissel]

Pitch

Currently Access Tokens are valid indefinitely. However for most applications this is not needed at all. Therefore I propose:

• Applications should be able to set expiration dates of their tokens
• All tokens should have an expiration date of e.g. 1 month by default
• This should apply retroactively
• There should be an easy way for Mastodon Admins to revoke all tokens for a specific app name.
• Users should be able to revoke all tokens at once, not just one-by-one

Motivation

Access tokens are a security risk. Most users forget, that they installed an app and forget to check their /oauth/authorized_applications settings. When using clients like elk etc. there is actually no way to check your authorised apps. Many Mastodon Projects are currently hobby projects without hardened security checks, so it is conceivable, that access tokens get leaked from time to time, even without accounting for nefarious actors. Many mastodon users have inactive accounts and wouldn't even notice if their tokens get stolen and used for spam. Given the high risk from spam to the fediverse and mastodon this is a fundamental risk to the entire network.

[trwnh]

refresh_token is a flow supported in e.g. pleroma, so it would be nice to see it in mastodon as well and to also encourage the ecosystem of apps to move toward refreshing their tokens instead of assuming they will continue to work forever.

[Lewiscowles1986]

So, can't an app just request a new access token? I am trying (and failing) to understand why limiting the lifetime of an access token, necessitates a refresh token. I'm not suggesting refresh tokens are not outlined in the spec as a way to do this, nor that they are incredibly common. Is this perhaps something about the process of obtaining an access token?

I am failing to understand the leap from "access tokens should expire" (strong agree); to "and we require refresh tokens as well as this work, in order for this work to complete". I Also think refresh tokens are separately valuable; but I just don't see what that has to do with access tokens specifically.

[trwnh]

@Lewiscowles1986 getting a new token requires obtaining user authorization again, which means having to login again and click allow. refresh tokens allow the app to not have to do this every single time.

[Lewiscowles1986]

Has anyone read https://doorkeeper.gitbook.io/guides/security/token-and-application-secrets ?
It speaks about hashing refresh tokens, which would necessitate disabling (IMO the foolhardy) reuse_access_token, which feels like more of a security faux pas than long-lived access tokens.

After all, does an access token grant access to an individual profile, or an entire server for mastodon? (Please say only a profile)

[Lewiscowles1986]

I Just created an app on phpc.social, which uses mastodon. I did not have to login to generate a new access token.

[ThisIsMissEm]

We are working towards refresh token support, as well as shorter-lived access tokens, however, we need to be very careful with how we implement this, such that we don't completely break the ecosystem.

You can see early work towards this in #30329 and #27948 — the phase out timeline is quite long though.

[ThisIsMissEm]

@Lewiscowles1986

I did not have to login to generate a new access token.

If you are already logged in with an active session, then you will not need to login again to complete the OAuth flow. If you've already confirmed access for an application, then the grant is automatically applied (rightfully or wrong), however, clients can override this through the non-standard force_login parameter, which is equivalent to prompt=consent in OIDC.

I'm going to be also looking into whether we can switch to a more standard prompt=... parameter, like that in OIDC.

[Lewiscowles1986]

following OIDC means getting better end-user security for Mastodon users.

[ThisIsMissEm]

We can't necessarily "follow" OIDC, but we can certainly align with it and reuse the same language for the same functionality.

[Lewiscowles1986]

Is BC the primary thing blocking use of the standard; or are there other standards of greater interest?

I guess I'm both impressed and a little frightend of someone who rather likes standards (formal thinking from others, generally more interested that gen-pop).

[Lewiscowles1986]

I've read #31129 #30329 and #27948

I can't work out how we are not agreeing @ThisIsMissEm

[ThisIsMissEm]

That is, Mastodon does not / never has implemented OIDC for API access. Changing to OIDC would be a major breaking change, which simply isn't an option.

We can however, slowly, align our OAuth 2.0 implementation with OIDC. So refresh tokens, public clients, token expiration, these are all things being worked on but will take significant time to complete, but we've made major steps forwards over the last 6 months.