Why You Should Care About OAUTH2 (4A)

From IIW

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

  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)

Retrieved from "https://iiw.idcommons.net/index.php?title=Why_You_Should_Care_About_OAUTH2_(4A)&oldid=5316"