1. Client sends a request of the form:
   • https://WIKI_AUTH_ENDPOINT/auth?response_type=code&client_id=CLIENT_ID& scope=SCOPE&state=STATE
   • State is a random string generated by the client which will be sent back to the client.
2. Server verifies that there is a logged-in user associated with the wiki
   • If not, redirect to Special:UserLogin
3. User is presented with the authorization dialog (client is not whitelisted)
4. If the user does not approve, an authentication failure is returned
5. If the user approves:
   • Server generates authentication code
   • Server redirects back to the client with:
     • https://REDIRECT_URI/cb?code=AUTH_CODE&state=STATE
6. Client sends a POST request to https://WIKI_AUTH_ENDPOINT/token with the following parameters:
   • grant_type=authorization_code
   • code=AUTH_CODE
   • client_id=CLIENT_ID
   • client_secret=CLIENT_SECRET
7. Server responds with and access token and expiration or an error
8. Configurable optional step to get user information from the server

• See also:
  • OAuth 2.0 Spec: RFC 6749
  • Simplified authentication workflow: https://aaronparecki.com/oauth-2-simplified/

• Client whitelisting (see step 3) is out of scope for this task but may be implemented later
• Research scope values
• Is there a standard approach for retrieving the user values?
  • While the implementation should be independent of client, see "Configuring the JSON User Endpoint" at https://meta.discourse.org/t/oauth2-basic-support/33879 for how to retrieve user values from Discourse to return user id, username, full name (optional), and email (optional)

Priority: Must Have

Acceptance Criteria:

Case 1:

1. User requests login from client
   • User is already logged in to the server (wiki)
2. User is presented with the authorization dialog
3. User authorizes server
4. RESULT: User is logged in to the client and returned user information is available

Case 2:

1. User requests login from client
   • User is already logged in to the server (wiki)
2. User is presented with the authorization dialog
3. User does not authorize server
4. RESULT: User is not logged in to the client

Case 3:

1. User requests login from client
   • User is already not logged in to the server (wiki)
2. User is presented with the log in page for the wiki
   • User successfully logs in to the wiki
3. User is presented with the authorization dialog
4. User authorizes server
5. RESULT: User is logged in to the client and returned user information is available

Case 4:

1. User requests login from client
   • User is not already logged in to the server (wiki)
2. User is presented with the log in page for the wiki
   • User successfully logs in to the wiki
3. User is presented with the authorization dialog
4. User does not authorize server
5. RESULT: User is not logged in to the client

Case 5:

1. User requests login from client
   • User is not already logged in to the server (wiki)
2. User is presented with the log in page for the wiki
   • User does not successfully log in to the wiki
3. RESULT: User is not logged in to the client or the server