Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dealing with Expiring Tokens #17

Open
EdwardHinkle opened this issue Apr 4, 2019 · 9 comments
Open

Dealing with Expiring Tokens #17

EdwardHinkle opened this issue Apr 4, 2019 · 9 comments

Comments

@EdwardHinkle
Copy link

@EdwardHinkle EdwardHinkle commented Apr 4, 2019

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
Copy link
Member

@aaronpk aaronpk commented Apr 4, 2019

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
Copy link
Author

@EdwardHinkle EdwardHinkle commented Apr 4, 2019

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
Copy link
Author

@EdwardHinkle EdwardHinkle commented Apr 4, 2019

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
Copy link
Member

@dshanske dshanske commented Apr 4, 2019

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

@vikanezrimaya
Copy link

@vikanezrimaya vikanezrimaya commented Mar 26, 2020

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
Copy link

@jamietanna jamietanna commented Aug 10, 2020

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
Copy link
Member

@dshanske dshanske commented Aug 16, 2020

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
Copy link

@jamietanna jamietanna commented Aug 16, 2020

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
Copy link
Member

@dshanske dshanske commented Aug 16, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants