Introduction to OAuth2

From IIW

OAuth 2.0

Tuesday 1B

Convener: Justin Richer

Notes-taker(s): Danielle Johnson

Tags for the session - technology discussed/ideas considered:

OAuth 2.0. What is it? Basic overview. Tokens. API Keys.

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

What is OAuth 2.0?

  • Delegation protocol



Resource Owner

  • Person/entity/policy/server with access to a web browser or API
  • The right to delegate access to API
  • Delegating access to the resource
    • Works with anything accessible on the web

Shares to client (piece of software access protective resource API) mobile app, server, javascript within web browser

  • Could be native or mobile

Trying to solve the problem of giving away access insecurely

  • Steal keys user it to log in as someone else
    • Only works if credentials can be stolen
    • Men in the middle attack (taking something someone used to prove identity and using it)
  • Ask for keys to share across apps, websites, etc
    • Ask for resource owner credentials and reply them to protected resource
      • Most people willingly give up info to share across resources and make life easier
  • What if instead of personal keys, there is a universal key (API key) to unlock anything (like an axe to break down the door and gain access)
  • Works really well in closed enterprise access

LDAP server with API Keys


  • Client must be completely trusted to be impersonating user
    • Does not work across security boundaries
  • Users may not be aware any share is happening

Service-Specific credentials

  • Special password (or token) only accessed by user
  • Doesn’t leak user’s password
  • Security great, usability is crap
    • More credentials to manage and lose
    • User transfers credential to app (usually by hand)

Automating the Process-Auth server dedicated to managing service specific tokens

  • Tokens given to client
  • Authenticates resource owners (users)
  • Authenticates clients
  • Manages authorization

OAuth Access Token

  • Represents delegation
  • Issues by auth server
  • Used by client (opaque to client)
  • Consumed by protect resource
  • Tokens can be many formats (it doesn’t matter)

We’ve all used it! Even when we don’t know it! (android phones, spotify, steam…)

Brief History OAuth 2.0

  • Circa 2006
  • HTTP password authentication common for API access
    • “Give me your password”
  • Internet companies have proprietary solutions for delegated access
    • BBAuth, AuthSub, a few others

OpenID comes along(no password)


  • 2 smaller sites want to connect their APIs for their users
  • Both use OpenID for users
    • No username/password to pass
  • Neither wants to use a proprietary solution

New Standard born

  • OAuth 1.0 published independently
    • No formal standard, people just use it
  • Session fixation attack found and fixed (intercept of information)
    • New version called OAuth1.0a
  • Community document is standard RFC5849 in IETF

People Use

  • OAuth1.0a solves major pain points for many people in standard and understandable ways
  • Google, Yahoo, and others replace their solutions with new standards

People Abuse

  • People decide to start using OAuth for off-label cases
    • Native apps
    • No use in loop
    • Distributed authorization systems

Version 2.0 framework

  • Modulization concepts
    • Separated previously conflated components
    • Added explicit extensibility points
    • Removed pain points of implementations
    • Standardized in RFC6749 and RFC6750

What does this mean?

  • Not a single protocol
  • Meant to be building blocks to use it for your own needs
  • Different ways to mix and blend ingredients
  • Not a single standard, it’s a set of standards for different use cases
    • Don’t use implicit tokens with native apps causes vulnerabilities

What OAuth isn’t

  • Not defined outside of HTTP
    • Core protocol defined only for HTTP
    • Relies on TLS for securing messages
    • There are efforts to use OAuth over non HTTP protocols
      • GSSAPI
      • OoAP
  • Not an authentication protocol
    • Relies on authentication in several places
      • Client authentication to token endpoint
      • Resource owner auth to auth points
    • Doesn’t communicate anything about user
    • However, authentication protocols can be built using
      • Auth (OpenID connect)
  • No user to user delegation
    • Allows users to delegate
  • No authorization processing
    • Tokens represent scopes and other auth info
    • Processing info is up to resource server
  • No token format
    • Opaque to client
    • Needs to be issued by auth server and understood by resource server, but free to use however they want
    • JSON web tokens (JWT) provide a useful common form
  • No cryptographic methods
    • Core OAuth relies on TLS for protecting info in transit
    • JSON
  • Not a single protocol

The authorization code flow-Canonical OAuth 2.0 transaction

Back Channel (no user involved)

  • Back channel uses direct HTTP connections between components, the browser is not involved

Front Channel

  • Front channel uses HTTP redirects through the web browser, no direct connections

Authorization Code

Step 1: add queries, get request

Step 2: Resource owner authenticates to the authorization server

Step 3: Resource owner authorizes client (OAuth allows to ask user allows cross domain authorization)

Step 4: Authorization server redirects resource owner back to the client with an authorization code

Step 5: Client sends the authorization code to the authorization server’s token endpointclient authenticates using its own credentials

Step 6: Authorization server issues an OAuth access token to the client

Step 7: Client accesses the protected resource using the access token

Tuple of token

  • Resource owner approved
  • Client that requested
  • Access rights delegated

Interpreting token

  • Shared data source
  • Pack info in token to parse and interpret (JSON Token)
  • Online lookup system

Client Credentials Flow (formally two-legged OAuth in 1.0)

  • Has no user or web browser making request
  • Autonomous client
  • Not acting on behalf of a user

Implicit flow

  • User and client are one unit
    • Implicit front type uses only the front channel since client is inside the browser

Resource owner password flow

  • Don’t use!
    • Don’t pass passwords… just don’t do it

PKCE: sending the challenge

  • Client generates code verifier and challenge (hashed secret passed from user to server), includes challenge in front-channel request to the auth server

PKCE: sending the verifier

  • API key, pass, and hashed secret passed from client to auth server)

Unifying Challenge

  • Regenerates challenge from verifier and compares it to previously sent challenge

Additional Notes:  Jin Wen

What is OAuth means to you: 

  • It is a delegation protocol, not authorization 

the following is a commonly mis-understood terminology: Client in OAuth.

A client: piece of software accessing resource on behalf of resource owner

Problems with universal keys: one key to unlock them all!

Problem of service-specific credential:

  • Yet another credential for users to manager and manage to lose
  • has to transfer the credential to the application, by hand

History of OAuth 2.0:

The problem started: Two smaller sites want to connect their APIs for their users starting at 2006

earlier OAuth 1.0 is RFC5849

session fixation attack change it to OAuth 1.0a

Cons of 1.0a:

  • Native app
  • No user in the loop
  • Distributed authorization systems (RSA signing)

Version 2.0: The framework

  • Modularized concepts
  • Separeted previously conflated components
  • Added explicit extensibility points
  • Removed pain points of implementers
  • Standardized in RFC6749

Killer pain in OAuth 2.0: using implicit flow in native app -- a big security flaw

What OAuth 2.0 is NOT:

  • Not defined outside HTTP
  • Relies on TLS for securing messages
  • There are efforts to use
  • NOT an authentication protocol --> OpenID Connect is, 
  • NOT an person to person authorization protocol --> see UMA
  • No token format: JSON Web Tokens (JWT) provide a useful common format
  • Token is opaque to the client
  • No cryptographic methods --> see JOSE

The Authorization Code Flow: deep dive


two type of comm channel: Back Channel and Front Channel

Front Channel: uses HTTP redirects through the web browser, no direct connections Back channel:  client communicate with Auth Server