OAuth 2.0 and OpenID Connect

Terminology

• Resource Owner

  The person, the user

• Client

  The application that is attempting to get access to the user’s account. It needs to get permission from the user before it can do so.

• Client ID

• Resource Server

  The API server used to access the user’s information.

• The Authorization Server

  The server that presents the interface where the user approves or denies the request. May be the same server as the resource server.

• Back Channel

• Front Channel

Authorization Code Flow

Why Not Implicit Flow?

1. You access the app in your browser and click its login button
2. The app responds with a redirect to the browser
3. The browser follows the redirect to Google
4. Google returns a hosted login form
5. You submit your username and password directly to Google
6. Google authenticates you and sends a redirect with a token in the URL
7. The browser follows the redirect to your Vue app, which parses the token out of the URL

Steps 6 and 7 above involve a redirect back to the Vue app in the browser. Redirects are HTTP GETs. As such, your only opportunity to get a token back to the app is to include it in the URL. The token is now sitting there in the browser history. It’s especially problematic if the token is long lived. And many people sync their browser history across multiple devices further expanding the attack.

Authorization Code with PKCE Flow

1. You access the app and click it’s login button. The app creates a random value v and hashes v to $

2. The app responds with a redirect to the browser including $

3. The browser follows the redirect to Google

4. Google stores the $ and returns a hosted login form

5. You submit your username and password directly to Google

6. Google authenticates you and sends a redirect with a short lived code α

7. The browser follows the redirect to Vue app, which extracts α from the url

8. The Vue app makes a POST request to Google with: a Client ID, v, and α

9. Google responds to the POST request with a token

Being stored in browser history is the one-time use temporary authorization code: α. The tokens are never passed through a URL.

On a mobile platform like iOS or Android, you could have a malicious app listening for a response from the first part of the flow (steps 6 & 7). Only the legitimate app will be able to pass the proper value for v to Google (since it created it) and Google can verify that it’s correct based on the hashed value $ it stored earlier.

OpenID Connect