Handling of temporary OAuth tokens

[sfussenegger]

Shouldn't connections have an expiry time? Probably along with new methods in ConnectionRepository to update the token and expiry time.

[habuma]

I think what you're talking about is refreshing an OAuth 2 access token using the refresh token that was granted by the provider along with the access token. If so, then that's definitely in the plans for M3.

[sfussenegger]

I'm not an expert for OAuth, that's why I planned using spring-social not sure what a refresh token is, gotta read up on this.

What I'm talking about is FB's cookie-based login. Every time a user visits my site there will be new access_token and expire timestamp. How should this be handled? And how should/will expired access_tokens stored in DB be handled?

[habuma]

Facebook's a strange one in that their access tokens expire, but they don't support refresh tokens. So, there's only two ways of dealing with expired tokens in FB:

- When it expires (either reacting to the expiration or to a 401 response) you'd need to send the user back to do FB authorization again.
- Ask for "offline_access" permission so that you get a non-expiring token.

If Facebook supported OAuth 2 refresh tokens, then you wouldn't have to re-authorize....you'd just send in the refresh token to renew the life of the access token. (Hopefully Facebook will support refresh tokens at some point in the future...perhaps when the OAuth 2 spec is final.)

In either event, these are scenarios that we're looking into addressing for M3.