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
- Very low barrier of entry
- #angrynerds
Works on a rough consensus model
- 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
- Where authorization server issues access tokens
Authorization endpoint
- Where the client sends the resource owner to authorize the token request
Extensions can define new endpoints
- e.g., Revocation endpoint
AuthZ Code
- Traditional 3-legged Oauth flow
- Best path for web servers
Refresh Tokens
- 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
Implicit
- Best path for in-browser clients
- Registered callback URL helps authentication client
- Client gets the token directly from the authorization endpoint
Username/Password
- Bootstrap old password -based systems
- Until they disappear
- Client prompts user for username an password
- Client presents
Client Credentials
- 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
Tow-legged Oauth 2
- MAC token signing
- Sign requests using client credentials
- Client credentials flow
Native Clients
- 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
- Clients don't have to store sensitivce user credentials (passwords)
TOFU
- 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
Trust Layers
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)