OAuth: I know what you did last summer... because I forgot to clear the cache - mattoattacko/class GitHub Wiki

Roles

  • 3rd Party Application (Client): the client is the application that is trying to get access to our user's account information. Must first get authorization from the user. *_ API (Resource Server)_: the API server used to access our users info.
  • Authorization Server: the interface where our user confirms or denies the request made. Often built as a separate component.

Creating Apps

  • First we need to register a new app before we can star the Oauth process.
  • We can prevent some user attacks by having a redirect URI send people to registered URIs. Must be protected, with https if possible.
  • Once our app is registered, we will receive a client ID and secret. Client ID's are public and can be used to build login URLs. The secret must be protected and kept as such.

Authorization

  • If our first step is getting authorization from our user, the next is to actually get our user authorization. Usually done via provided user interface.
  • There are different grant types for various uses; Authorization Code (for browser based apps), Password, Client Credentials (for application access), and Implicit (no longer in use very often).

Web Server Applications

  • Most common type of application we find dealing with OAuth servers. Web apps are written server-side and run with the source code not publicly available. Uses client secrets to communicate with the auth server.
  • To start authorization, send our user a log in link. This link includes Response_Type=Code (shows that our server is expecting to get an auth code), Client_ID (received when we created the app), Redirect_URI (tell the URI where to return the user after auth is complete), Scope (values that show what parts of our user's account we want to access), and State (random string generated by our app that we use to verify).
  • After given the auth code for an access token, we will see the same general pattern as above; grant_type=authorization_code, code=AUTH_CODE_HERE, redirect_uri=REDIRECT_URI , client_id=CLIENT_ID, client_secret=CLIENT_SECRET.

Single Page Applications

  • SP apps (aka browser-based apps) run entirely in the browser after loading source code from the website that they are on. Not secure and thus the client secret should not be used.
  • Authorization here looks like: response_type=code , client_id , redirect_uri, scope, state.

Mobile Applications

  • As with browser-based applications, mobile applications can't keep our client's secret safe. Thus they use OAuth flow that does not need it.
  • We can get authorization by making a β€œlog-in” button that sends our user to either the native application of the service on their phone, or a mobile page that hosts the service.

Web Browser

  • If no application is available, we can have the user use their mobile browser. Avoid using embedded web view as it kinda looks like we are performing a phishing attack. Best to use the native mobile browser.

Other Grant Types

  • Password: used to exchange a username and pw directly for an access token. Should only be bused by apps created by the service the user is logging in to. Server replies with an access token just like the other grant types presented above.
  • Application access might be needed if the application needs to access the token as its self, rather than the user.

Using OAuth to Access Google APIs

  • First we need to get OAuth client credentials from the Google API console.
  • Next, our client application needs to request an access token from the Google Authorization Server. The GSA extracts a token from its response and sends it to the Google API that we are trying to access.
  • Obtain OAuth credentials from the Google API Console β†’ Obtain access token from the Google Auth server β†’ Send our aquired access token to the API we want β†’ Refresh the access token when necessary.