Dealing with Expiring Tokens

[EdwardHinkle]

Currently IndieAuth and Micropub don't talk about how to deal with expired tokens, whether auto-expiring tokens or revoked tokens. To get a new token, most Micropub clients will make you log out and back in. However in the new Micropub client era with native apps and Reader web apps, you might not want to have to log out and back in just to refresh your token.

There was some brainstorming in chat about this.

A Micropub Client supporting expiring tokens should do two things:

1. A Micropub app should look for an "expires_in" attribute being returned with the access token. If it is, after that time frame, if the user tries to start a new post it should prompt them to re-authenticate without logging them out, so they can obtain a new token.

2. A Micropub app should look at error status codes returned when trying to post to a Micropub endpoint (or when trying to do Micropub Queries). If 401 is returned, the app should consider the existing access token is invalid and should re-authenticate without logging them out, so they can obtain a new token.

When to log out: If in the process of re-authenticating the Micropub client is not given a new access token, at that point posting should be disabled. How the Micropub client handles the UI of that is up to the app, whether people still have access to drafts, etc.

A Micropub Server supporting expiring clients should consider two things:

1. If they have auto-expiring tokens, they should include the expiration time in terms of second until expired in the expired_in attribute when providing the access token to the client.

2. When authenticating a Micropub request or a Micropub query, if the access token is no longer valid (it's revoked or expired or otherwise malformed) it should return a 401 status error code. This will tell the Micropub client it needs to re-authenticate.

[aaronpk]

This sounds great, and to be clear, none of this is new behavior defined by Micropub or IndieAuth, it's all part of the existing OAuth 2.0 spec that IndieAuth is based on. We can call this out explicitly but we should not be defining any new normative behavior and instead just reference OAuth 2.0.

[EdwardHinkle]

Correct, none of that is new, just that we should define that is IS something clients and servers should do. I think currently it's easy to overlook. I for example can revoke tokens on my IndieAuth server, but if I were to revoke the token for Indigenous for iOS I would have to completely log back out.

[EdwardHinkle]

It took a bit of hunting in OAuth 2.0 to decide what all the right values were, so bringing that into the actual Micropub spec referring to OAuth 2.0's guidance but saying it SHOULD be supported or just adding more concrete information on the wiki "how-to" Micropub page. I'm flexible either way.

[dshanske]

I would like to implement expiring tokens in my indieauth endpoint.

[vikanezrimaya]

me too! My token endpoint project uses redis keys to store tokens, so it would be fairly easy to make them expire by setting corresponding redis keys to expire.

[jamietanna]

I would also like to support this for two reasons:

• as a means to ensure that an access token's leak can be minimised in impact
• as a means to ensure that ie every 30 days I am able to re-consent to an application being able to perform actions as myself

(Originally published at: https://www.jvt.me/mf2/2020/08/ghyek/)

[dshanske]

Thinking about the original proposal. Expires_in is part of the OAuth2 process already, I would think the first need is for one or more Micropub apps to look for and store this information and if present, surface it to the user somehow. For example, store value. If token returns unauthorized, check whether it had an expiry and surface this.

Separately, I'm thinking of adding it to the IndieAuth authorize page of my endpoint, as a user selectable option(indieweb/wordpress-indieauth#181)

[jamietanna]

Would that be needed? Generally with OAuth2 a 401 would indicate there is some issue with the token and to either refresh a refresh token (if one was issued) or to request the user re-authorise the application.

Unless we're recommending the use of a refresh token, I'm not sure if we'd need clients to keep an eye on the expires_in from the initial issue, or calls to introspect on the token endpoint

(Originally published at: https://www.jvt.me/mf2/2020/08/bhehh/)

[dshanske]

We aren't, but in my opinion, good user experience is to explain that they got an expiring token.. curious what others think

[dshanske]

Being as we now have expiring and refresh tokens in IndieAuth, the question here now pivots to recommendations for Micropub clients, I would think.

[vikanezrimaya]

One example of how a client could act:

• If issued a refresh token, client SHOULD assume the access token will be rather short-lived, and stash the refresh token together with the access token.
• If the request fails with a 401 Unauthorized, client that has a refresh token previously stashed MUST transparently retry the request after refreshing their token. If the refresh was denied (e.g. refresh token got revoked/expired), it should pass through the previous 401 Unauthorized error.
• Client SHOULD check whether the token was valid by using the introspection endpoint. They MAY do so on launch, or on certain intervals, depending on the client. Using the introspection endpoint could also allow to update some metadata — from what I remember, introspection endpoint with a profile scope reveals a bit of metadata about user that could be displayed in an account selector UI.