OAuth - Don’t Throw the Baby Out with the Bathwater

OAuth 2.0 - Don’t Throw the Baby Out with the Bathwater

Apigee@apigee

Greg Brail@gbrail

Ed Anuff@edanuff

groups.google.com/group/api-craft

youtube.com/apigee

slideshare.net/apigee

@edanuffEd Anuff

@gbrailGreg Brail

What happened?

OAuth 2.0 refresher course

OAuth in the world

Next steps and recommendations

Overview

WHAT HAPPENED?

Eran Hammer-Lahav, one of the spec leads, quit

He blogged about how screwed up OAuth 2.0 is

He got a lot of attention

Some other people blogged about his blog

What happened?

One of the primary authors of OAuth 2.0 disowned it.

So is this an excuse to give up on OAuth?

We don’t think so

Why does it matter?

OAUTH 1.0 & 2.0 RECAP

Start with:Application credentials (ID and secret)Authenticate the userWeb browser redirectGet a token and secretSign with it on every request

OAuth 1.0a recap

Signatures are hard

This may seem minor but ask the “developer on the street” about OAuth and you will get some version of this response

What was wrong with OAuth 1.0?

A family of specs

The “authorization framework”

Bearer token spec

SAML, JWT, and other token specs

More specs

What is OAuth 2.0?

Start with “client credentials”

These identify the application requesting authentication

Optionally authenticate the user

There are many “grant types” that define this

Get an “access token”

Uniquely identifies the user / application / device

Send the access token on every request

What does it really do?

In OAuth 2.0, “app credentials” are essentially a username / password that identifies a single application

OAuth 2.0 grant types

Grant Type What You Need How You Authenticate User

Authorization Code App CredentialsEnd-user credentials

Web browser redirect. Web app determines what is required

Implicit Grant App CredentialsEnd-user credentials

Web browser redirect optimized for script-heavy web apps

Resource Owner App CredentialsEnd-user username / password

Send username / password in API call

Client Credentials App Credentials You don’t

Extensions SAML token, JSON web token Depends on the extension spec

For reference: OAuth 1.0 only supported a “Mac” style of token

OAuth 2.0 token types

Token Type What it Is Signed? Spec Status

Bearer A big random number

N Proposed Standard

HTTP-MAC Signed request Y Very old

Security considerations

Token Type On the Wire On the Disk

Bearer Totally open – requires SSL to prevent token theft or misuse

Hash it just like a password

“Mac” Secure – secret cannot be reverse engineered and “nonce” prevents replay. No SSL required.

Server must access it in clear text

Three grant types require user authenticationMany people call these “three-legged”They involve the app, the API, and the user

One does not – it just uses the app credentialsMany people call this “two-legged”

Minor fact – the words “leg” and “legged” are not present in the spec

What about “legs?”

Every OAuth 2.0 token can have “scopes”

Identify what the token can doFor instance:

READ, WRITE, DELETEor

SEND_SMS, SEND_MMS, GET_LOCATION, PAY

Scopes

APIs may return two tokensAccess token with an expiration timeRefresh token with no expiration time

Refresh token used to get a new access tokenNo additional user authentication is required

Refresh tokens

What if the access token is compromised?Harder to guess if it has an expiration timeHarder to use a stolen token from a device

So why is the refresh token harder to steal?It isn’tIt’s still stored on the device or web server

Why refresh tokens?

It supports a two-tier architecture:Authorization grants, token generation,

and all that on a complex, slow serverAccess tokens in a scalable caching layerNo need for complex cache invalidation

What if the main OAuth system already scales?Then there is no reason to use refresh tokens

Why refresh tokens, really?

OAUTH IN THE WORLD

There are many more specs – check the IETF process:

http://tools.ietf.org/wg/oauth/

Status of key specs

Spec Revision Status

Authorization Framework 31 Proposed Standard

Bearer Token 23 Proposed Standard

JWT Token 3 Draft

JWT Bearer Token 1 Draft

SAML 2 Token 13 Draft

HTTP MAC Token 1 Draft; Last update February

How a spec grows up to become a “law:”1. Draft2. Proposed Standard3. Draft Standard4. Internet Standard

Thanks to Aaron Parecki from Geoloqi for this table

Status of big APIs

Provider Spec Revision Reference

Foursquare 10 http://aaron.pk/2YS

Google 10 https://developers.google.com/accounts/docs/OAuth2

Facebook 10* https://developers.facebook.com/docs/authentication/

Windows Live 10 http://aaron.pk/2YV

Salesforce 10 http://aaron.pk/2YW

GitHub 7 http://developer.github.com/v3/oauth/

Geoloqi 10 https://developers.geoloqi.com/api

31 Apigee Enterprise customers use OAuth 2.020 have “two-legged OAuth” aka “client credentials”19 have “three-legged OAuth”8 have both

6 Customers have OAuth 1.0a

Many customers have neither“API Key” authentication onlyUsername / passwordSSL, many other options

OAuth in production - versions

Thanks to Amit Chakraborty from Apigee for this data

It’s not just about tokens

How is the user authenticated?All but two Apigee customers use existing web pages

or directory servers for user authentication

How is consent granted to issue the token?Usually done through the browserMany different ways to implement it

Two more steps to OAuth

NEXT STEPS ANDRECOMMENDATIONS

For web apps that use APIsOAuth is the most standard, secure choice

For mobile / native apps that use APIsOAuth has advantages over alternatives

Uniquely identifies the end user, device, and appCredentials may be revoked at any time

For server-to-server APIsUse OAuth if you use it for other things too

Why use OAuth?

Stick with the basics:

Bearer tokens

No refresh tokens

No extensions

Keeping OAuth under control

Questions

groups.google.com/group/api-craft

THANK YOUQuestions and ideas to:

@gbrail@ edanuff

groups.google.com/group/api-craft