Introduction to OAuth2

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

Problems

• 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)

Problem

• 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

Resource

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