Why You Should Care About OAUTH2 (4A)

Why care about OAuth 2 (4A)

Convener: Justin Richer

Notes-taker(s): Ross Foard

Tags for the session - technology discussed/ideas considered:

Discussion of OAuth and history of the protocol and how it will emerge to be very prevalent

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

Oauth is an open authorization protocol (not single sign-on)

A scenario

A user has a client site hey log into and a service provider they log into

It solves how the client to service provider side of the triangle

SSO, by contrast allows me to log into the service provider with my client credentials

Developer Key Approach - the Client gives the service account key to the service provider

Give me you keys approach - log into client and give the client my service provider keys (like LDAP)

There has to be a better way to do this:

Oauth approach

Log into the Client, user authorizes login to the service provider (by redirection) with a ticket and binds it to the session on the Client. The Client and service provider now interacts through this authorized channel and a token is generated and grants the access to the service provider. This token is used between client and service provider.

Persistence on the token is by time, by number of uses or by client. Also have access and refresh tokens.

History of Oauth

November 2006, Twitter Ma.gnol.ia and others want to use OpenID and connect between service

OpenID can't close the Client to Service Provider exchange (bottom of triangle)

FlickrAuth, AuthSub, BBAuth were trying to do this stuff with Tokens replacing direct credentials

Explicit user consent crossing trust domains

Standardization

Take the best practices and experience from existing solutions together into one

protocol, thus Oauth 1.0

Revisions 1.0a, closed session fixation attack

RFC 5849 cleaned up editorial language

Standard libraries for AuthZ

Oauth 2.0 was developed

Because Oauth 1.0 tried to solve may problems at once with a single solution Oauth WRAP tried to solve a slightly different problem set in a novel way

Solution: divide the problem space and combine the approaches
 * Methods for getting a token
 * Methods for using a token to get stuff
 * Methods for signing an HTTP request

Not backwards compatible, but co-exist

\Oauth 2 is not wire-compatible with OAuth1 on purpose

New to Oauth 2

Different token styles
 * User vearer tokens over SSL

Multiple token flows for different client types
 * Higher flexibility for deployment

Refresh tokens
 * Allows for easy rotation of access tokens

Conceptual separation of protected resource and authorization server
 * Can still be combined (and often are) in one box

Extensibility and error handling
 * Clear paths forward

IETF Working Group

Connected by freely-joinable mailing list Works on a rough consensus model
 * Very low barrier of entry
 * #angrynerds
 * Preference towards demonstrated functioning code

International and cross-industry participation

Chartered in 2009
 * Originally to make Oauth 1.1

Timeline of Oauth 2
 * Oauth 1, 2007
 * 2-Legged Oauth
 * Oauth 1.0a 2009
 * RFC 5849 2010
 * Oauth WRAP 2009
 * Oauth 2.0 2010

Blew up in 2011 - All in the same protocol
 * MAC Token - 2 legged world
 * Oauth2 Core - Oauth 2
 * Bearer Token - Oauth WRAP

JWT, JWS, OpenID Connect, SWD, Dynamic Registration, UMA, SAML Binding

Going through draft review

Will have an RFC this year, will know more in March

Bearer, MAC, SAML-binding drafts also going forward now
 * Security Consideration document to follow

Oauth2 Endpoints

Token endpoint Authorization endpoint Extensions can define new endpoints
 * Where authorization server issues access tokens
 * Where the client sends the resource owner to authorize the token request
 * e.g., Revocation endpoint

AuthZ Code Refresh Tokens Implicit Username/Password
 * Traditional 3-legged Oauth flow
 * Best path for web servers
 * Can be issued alongside of access tokens
 * Allow for rotation of access tokens without asking the user again
 * Client calls token endpoint directly
 * Can have different expiration’s
 * Refresh token: long grant, saved by client between sessions
 * Access token: short grant, deleted at end of session
 * Best path for in-browser clients
 * Registered callback URL helps authentication client
 * Client gets the token directly from the authorization endpoint
 * Bootstrap old password -based systems
 * Until they disappear
 * Client prompts user for username an password
 * Client presents

Client Credentials Tow-legged Oauth 2 Native Clients TOFU Trust Layers
 * Client authorizes a transaction directly
 * Not on behalf of a particular user
 * Server-to-Server (better than developer keys)
 * Tokens are rotated a lot faster than credentials
 * Make use of scoping and delegation
 * Can separate authorization server forum protected services
 * Parameter and value assurance via signatures
 * Without requiring a body-signing protocol
 * Light-weight protocol
 * MAC token signing
 * Sign requests using client credentials
 * Client credentials flow
 * Can't store client passwords securely
 * Can store tokens securely
 * Rely on browsers for user authentication
 * Embedded or external application
 * Must support callback of some kind
 * Embedded web server (http://localhost/)
 * Custom scheme (app://oauthe)
 * Hosted callback landing page
 * Why Use Oauth here?
 * Clients don't have to store sensitivce user credentials (passwords)
 * Clients never enen have to see the password
 * Misbehaving cleitnes can be reviked by users
 * Trust on first use
 * First time through, ask
 * "You have never allowed this before, this is what I can say about them, is that OK?
 * Subsequent times tof through

Whitelist - Trusted partners, business contracts, customer organizations, trust frameworks (Organization decides)

Graylist - user based trust decisions, follow TOFU model, keep logs, OAUTH has consent forms built in

Blacklist - can't get there (Organization decides)