OAuth - Use of refresh tokens in "social sign on"

Question

The normal flow for OAuth2 as described in this SO reply is as follows:

• Send API request with access token
• If access token is invalid, try to update it using refresh token
• if refresh request passes, update the access token and re-send the initial API request
• If refresh request fails, ask user to re-authenticate

This is all well and good for most API calls, but I wonder one thing: Authentication.

When a user attempts to sign in to my fancy new webapp using their favourite service, should I use their refresh token (or cached access token in the case of OAuth1) to attempt a sign in, or should I always go and get a fresh token from the service provider (Google, Facebook, etc) and discard the stored access and refresh tokens?

Answer 1

User authentication and OAuth 2.0 are two different things. The difference is explained in detail in: http://oauth.net/articles/authentication/. Even when building user authentication/SSO protocols on top of OAuth 2.0 - which is what OpenID Connect does and some vendor-specific implementations - the refresh_token still always applies to the access_token not to the user authentication event or identity token.

You can not use a refresh token on its own to refresh a user's login session since some interaction with the user (may be active, may be passive) through the browser is required to confirm that the user is (still) present.

To refresh a user's login session you will always have to redirect to the identity provider and get fresh authentication information. Note that that interaction will probably also give you a new refresh token that could be used to refresh the access token.