farmOS OAuth2 Identity Provider

Regarding OAuth2 and Grant Types we might use in farmOS:

This chart from the simple_oauth PHP library is a great reference. Click on the grant types listed on the left menu for more detailed descriptions!

There are three categories of grants - 1st party, 3rd party and Machine. The Client Credentials grant is the only grant used for machine authentication - it doesn't have to be connected to a user account, and does not require user credentials. All other grants will provide clients with 'Access Tokens' and 'Refresh Tokens' to authenticate against a farmOS server. The idea is that 'Access Tokens' expire relatively quickly, after a day or less. 'Refresh Tokens' expire after 2 weeks or so. (This timing is all configurable). When an 'Access Token' expires, a new one can be requested using the 'Refresh Token'.

"Password Grants" are used for 1st party authorization. They require the user credentials to obtain an access token. This could work in farmOS Field Kit when it is installed as a native application on mobile devices. This grant requires a single POST to the farmOS server with the grant type, client information, and user credentials. farmOS returns an Access Token and Refresh Token.

"Authorization Code" and "Implicit" grants are used for 3rd party situations. These grants are two-step:
- First the client sends a POST to the farmOS server, redirecting the user to an 'Authorization' page hosted on a farmOS server . The 'Authorization' page authenticates the user with a login form, and allow them to approve the OAuth2 "Scopes" the requesting client wants access to.
- Then farmOS returns an Authorization Code, which the app uses to POST again and receive an Access token and Refresh Token.

Authorization vs Implicit
- If the 3rd party app has a server, then we would use "Authorization Code" grant. This would work for the farmOS-Aggregator. The Aggregator can save the Access Token and Refresh Token in the background.
- "Implicit" grants are used for apps that run entirely on the front end. This grant type isn't as secure because the app storage is easily accessible. farmOS Field Kit would use this when running in a browser. The "Implicit" grant is different from Authorization in that it is only one step - an access token is immediately returned after logging in on the farmOS server. Also, no refresh token is given to the client.

Other considerations for OAuth in farmOS:
- Ideally the OAuth module can use Drupal Roles for resource access control and permission handling. Best practice would be to create additional Roles for each client type that will authenticate via OAuth2, and only give the subset of permissions required to that Role. Aggregator clients could have "Aggregator_Read" "Aggregator_Edit" and "Aggregator_Delete" roles - depending on WHO owns the aggregator, only the require CRUD Roles could be assigned to that OAuth2 client.
- I believe we have multiple options for authenticating farmOS API Clients (farmOS.js and farmOS.py) - Looking at Google's OAuth2 implementation it looks like they use the Client Credentials Grant. This just requires going into the server (Google's API Console, or farmOS OAuth2 config page) creating a new client, and copying the client_id and client_secret into your API Client. It can use these to request a token. Other versions on Google's site use AuthorizationCode grants, too, however, and require you to do a little more work. There are options

Looking at the modules, simple_oauth certainly looks better than oauth2_server .... but simple_oauth is D8 only. Looking into how we could potentially migrate from oauth2_server to simple_oauth when farmOS goes from D7 to D8. Tracking this in this issue.