The purpose of this document is to design an oauth flow that can be re-used in any plugin that requires oauth in order to talk to the system that is being integrated with.
1. General concepts
Before using OAuth2 usually user has to create an application via service site (e.g. Twitter) and register redirect uri, than receive a client_id and client_secret. Which will be used by an application during authentication.
The further steps are shown in the diagram below:
We are implementing grant types "Authorization Code Grant" and "Refresh Token". Other types are not suitable or rarely used. Click here for some context.
Input values of the module:
Name
Description
Callback URL
A page where authCode is sent when user enter login and password. This address does not need to publicly accessible.
Auth URL
A page, where the user is directed to enter his credentials.
User should obtain this when registering the OAuth2 application in the service (e.g. Twitter).
Client Secret
User should obtain this when registering the OAuth2 application in the service (e.g. Twitter).
Scope
This is optional.
Scope is a mechanism in OAuth 2.0 to limit an application's access to a user's account. An application can request one or more scopes, this information is then presented to the user in the consent screen, and the access token issued to the application will be limited to the scopes granted.
All the APIs I checked: Google APIs, PayPal, WordPress, Microsoft Azure, Okta support refreshing access token. Actually this is parf of RFC. The only API which does not is Facebook. Instead they use concept they have made up called fb_exchange_token. Here's more info. Since facebook is widely spread, I suggest we should handle this separately. For facebook we should UI should put accessToken intead of refreshToken to secure store on step #11. And on step #13 backend needs a request to refresh it.