Change Details

# 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. # Server verifies that there is a logged-in user associated with the wiki # User is presented with the authorization dialog (unless the client is whitelisted) # If the user does not approve, an authentication failure is returned # If the user approves: -- Server generates authentication code -- Server redirects back to the client with: --- `https://REDIRECT_URI/cb?code=AUTH_CODE&state=STATE` # 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 # Server responds with and access token and expiration or an error # Configurable optional step to get user information from the server - See also: -- OAuth 2.0 Spec: [[ https://tools.ietf.org/html/rfc6749 | 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: # User requests login from client -- User is already logged in to the server (wiki) # User is presented with the authorization dialog # User authorizes server # RESULT: User is logged in to the client and returned user information is available Case 2: # User requests login from client -- User is already logged in to the server (wiki) # User is presented with the authorization dialog # User does not authorize server # RESULT: User is not logged in to the client

# 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. # Server verifies that there is a logged-in user associated with the wiki # User is presented with the authorization dialog (client is not whitelisted) # If the user does not approve, an authentication failure is returned # If the user approves: -- Server generates authentication code -- Server redirects back to the client with: --- `https://REDIRECT_URI/cb?code=AUTH_CODE&state=STATE` # 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 # Server responds with and access token and expiration or an error # Configurable optional step to get user information from the server - See also: -- OAuth 2.0 Spec: [[ https://tools.ietf.org/html/rfc6749 | 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: # User requests login from client -- User is already logged in to the server (wiki) # User is presented with the authorization dialog # User authorizes server # RESULT: User is logged in to the client and returned user information is available Case 2: # User requests login from client -- User is already logged in to the server (wiki) # User is presented with the authorization dialog # User does not authorize server # RESULT: User is not logged in to the client

# 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. # Server verifies that there is a logged-in user associated with the wiki # User is presented with the authorization dialog (unless the client is not whitelisted) # If the user does not approve, an authentication failure is returned # If the user approves: -- Server generates authentication code -- Server redirects back to the client with: --- `https://REDIRECT_URI/cb?code=AUTH_CODE&state=STATE` # 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 # Server responds with and access token and expiration or an error # Configurable optional step to get user information from the server - See also: -- OAuth 2.0 Spec: [[ https://tools.ietf.org/html/rfc6749 | 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: # User requests login from client -- User is already logged in to the server (wiki) # User is presented with the authorization dialog # User authorizes server # RESULT: User is logged in to the client and returned user information is available Case 2: # User requests login from client -- User is already logged in to the server (wiki) # User is presented with the authorization dialog # User does not authorize server # RESULT: User is not logged in to the client