Skip to content

Instantly share code, notes, and snippets.

@kosmakoff
Created October 18, 2016 12:22
Show Gist options
  • Save kosmakoff/daa65bbec28235334054e4f89bec44eb to your computer and use it in GitHub Desktop.
Save kosmakoff/daa65bbec28235334054e4f89bec44eb to your computer and use it in GitHub Desktop.
OAuth flows cheat-sheet
  • User interaction involved
    1. Authorization code
      This grant type is most appropriate for server-side web applications. After the resource owner has authorized access to their data, they are redirected back to the web application with an authorization code as a query parameter in the URL. This code must be exchanged for an access token by the client application. This exchange is done server-to-server and requires both the client_id and cli ent_secret, preventing even the resource owner from obtaining the access token. This grant type also allows for long-lived access to an API by using refresh tokens.
    2. Implicit grant for browser-based client-side applications
      The implicit grant is the most simplistic of all flows, and is optimized for clientside web applications running in a browser. The resource owner grants access to the application, and a new access token is immediately minted and passed back to the application using a #hash fragment in the URL. The application can immediately extract the access token from the hash fragment (using JavaScript) and make API requests. This grant type does not require the intermediary “authorization code”, but it also doesn’t make available refresh tokens for long-lived access
    3. Resource owner password-based grant
      This grant type enables a resource owner’s username and password to be exchanged for an OAuth access token. It is used for only highly-trusted clients, such as a mobile application written by the API provider. While the user’s password is still exposed to the client, it does not need to be stored on the device. After the initial authentication, only the OAuth token needs to be stored. Because the password is not stored, the user can revoke access to the app without changing the password, and the token is scoped to a limited set of data, so this grant type still provides enhanced security over traditional username/password authentication.
  • User interaction not involved
    1. Client credentials
      The client credentials grant type allows an application to obtain an access token for resources owned by the client or when authorization has been “previously arranged with an authorization server.” This grant type is appropriate for applications that need to access APIs, such as storage services or databases, on behalf of themselves rather than on behalf of a specific user.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment