OAuth Cheatsheet

oauth-cheetsheet.txt

OAuth (Open Authentication)

OAuth Client - e.g. My Server
OAuth Provider - e.g. Facebook Server

1. Register the OAuth Client on the OAuth Provider
2. It gets back an Client ID and a Client Secret
(On FB you do this manually by creating a developer account)
3. We want to authorize a user via the OAuth Provider
   We send to "GET: provider.com/oauth/authorize?" with
     - The Client ID (so that the OAuth Provider knows who we are)
     - A Redirect URI (where we implemented custom code to catch the user as they're coming back into our system)
4. The OAuth Provider asks the user whether he allows the OAuth Client to have access to his user information
5. When the user grants access: The OAuth Provider responds by redirecting the user back to the Redirect URI given by the OAuth Client
   The response includes a parameter "code" which has a one time use kind of unique Token that can then be exchanged for an Access Token
6. The OAuth Client takes that code and sends "POST: provider.com/oauth/access_token" to the OAuth Provider
   That Request includes:
     - The code
     - The Client ID
     - The Client Secret (both retrieved from the Provider in Step 1 + 2)
   This ensures that the OAuth Provider knows that no one is faking being the OAuth Client.
7. When all of those parameters are correct the OAuth Provider will send back an Access Token to the OAuth Client
8. Now the OAuth Client has access to everything the user would be able to get
   (like "GET: /users/me/friends" to get the users FB friends with the Access Token)
9. The OAuth Client sends all upcoming requests to the OAuth Provider with the Access Token
10. The OAuth Provider then knows that the OAuth Client is behaving like that user and responds with the appropriate results

OAuth...
* ...works over HTTPS
* ...authorizes devices, APIs, servers, and apps with access tokens rather than credentials
* ...has 2 versions: 1.0a and 2.0 (they are completely different + can not be used together + are not backwards compatible)
* ...is a delegated authorization framework for (REST) APIs
* ...enables apps to obtain limited access (scopes) to a user's data (without giving away a user's password)
* ...decouples authentication from authorization
* ...supports server-to-server apps, browser-based apps, mobile/native apps, and consoles/TVs
* ...can be seen as hotel cards, but for apps
  1. Authentication at the front desk to get it
  2. After authenticating and obtaining the key card you can access resources across the hotel

The OAuth process
1. App requests authorization from User
2. User authorizes App and delivers proof
3. App presents proof of authorization to server to get a Token
4. Token is restricted to only access what the User authorized for the specific App

OAuth vs. Direct authentication

The password anti-pattern


Roles in OAuth 2.0
* Resource Owner
* Resource Server
* Client
* Authorization Server

These Roles in Alexa
* Resource Owner - The Enduser that wants to connect his thirdparty account to a specific Alexa Skill
* Resource Server - The server hosting the resources the user wants to access via Access tokens
* Client - The app making the requests to the resource server: The Alexa service
* Authorization Server - The server that authenticates the identity of the resource owner and issues access tokens

The Resource Server and Authorization Server can be the same server.

Account Linking in practice
* Only via the Alexa App
* Possible Account Linking situations
  * On initial enabling of the Skill
  * After making a request that requires authentication. In this case, your skill returns a LinkAccount card, and the user can start the process from the card in the Alexa app
* When the app calls the Authorization URL, it includes the following query string parameters:
  * state
  * client_id
  * response_type
  * scope
  * redirect_uri

OAuth grant types
* Authorization code grant - 
* Implicit grant - 

OAuth Configuration for an Alexa Skill
* Provide an Authorization URL in the Developer Portal