oauth today - files.meetup.comfiles.meetup.com/17533002/oauth-slides-greg.pdf · for reference:...

©2015 Apigee Corp. All Rights Reserved.

OAuth Today Greg Brail


Overview

OAuth Purpose and Overview

State of OAuth Today

Implementation Challenges


We all understand the idea of a service

APIs, web sites that support mobile apps – these are all services

We all understand password-based security:

Need to provide your credentials in a secure way to gain access

Services are used by applications

Your web browser is merely one application

Services and passwords don’t mix well

How many applications have your password?

Do you trust them all? Are you sure?

Motivations Behind OAuth


OAuth is another way to authenticate to a service

Imagine that you had a different password for every service

(Already do? You are in a tiny minority.)

Imagine that you had a different password for every application

A compromised application can’t wreak as much havoc

Imagine that you can’t possibly remember it or write it down

Instead, it is stored by the application that needs it

That’s what OAuth does.

What is OAuth?


What does it Look Like?

5


What are the Parts of OAuth?

A family of specs

The “authorization framework”

Bearer token spec

SAML, JWT, and other token specs

More specs


Why was OAuth Created?

OAuth 1.0

Solve SSO between web apps that consume each other’s APIs

OAuth 2.0

Build a framework to solve all that and more

7


What does OAuth do?

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 is OAuth Good For?

Web apps that consume APIs OAuth provides a way to secure without sharing the password

Mobile apps that consume APIs OAuth provides a convenient token that may be stored on device

Mobile apps that consume unauthenticated APIs OAuth is a convenient framework for tracking devices and apps

9


What is OAuth Not so Good For?

Command-line tools for systems management “Basic” authentication or two-way TLS may be simpler But some tools do it very nicely

Server-server communication

OAuth can still be effective but two-way TLS may be simpler But OAuth makes it easier to support JWT and SAML

10


How is OAuth Different?

Application is always authenticated

End User is optionally authenticated

Result is an API-friendly cookie-like access token

Bearer token expires periodically, and there are various refresh strategies

11


How does it Do that?

OAuth 2.0 is all about exchanging user credentials for a bearer token How you do it depends on the use case:

Web app – web browser redirect to a “login” page Mobile app – ask the user for username and password Mobile app with web browser – open a web browser window Unauthenticated app – exchange “app credentials” for a token App using SSO – exchange a signed JWT token for a bearer token Enterprise SSO – exchange a set of signed SAML assertions for a bearer token

12


OAuth 2.0 Grant Types

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

Grant Type What You Need How You Authenticate User Authorization Code App Credentials

End-user credentials Web browser redirect. Web app determines what is required.

Implicit Grant App Credentials End-user credentials

Web browser redirect optimized for script-heavy web apps.

Resource Owner App Credentials End-user username / password

Send username / password in API to get bearer token.

Client Credentials App Credentials You don’t. JWT Bearer Token App Credentials, signed JWT You did it when you made the JWT.

SAML Bearer Token App Credentials, SAML assertions You did it when you made the SAML.


What are “Legs” and How Many do I Need?

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

One does not – it just uses the app credentials

Many people call this “two-legged” Minor fact – the words “leg” and “legged” are not present in the spec


Token Types

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

Token Type What it Is Signed? Spec Status Random Bearer Random bytes N Compatible with the standard Signed Bearer Signed JWT Y Compatible with the standard HTTP-MAC Signed request Y Not part of OAuth 2.0


Token Type On the Wire On the Disk Random Bearer Open – requires TLS to prevent token theft or misuse Hash it just like a password Signed Bearer Open – requires TLS No need to store it HTTP-MAC Secure – secret cannot be reverse engineered and

“nonce” prevents replay. No SSL required. Server must access it in clear text

Security Considerations of Token Types


Scopes

Every OAuth 2.0 token can have “scopes”

Identify what the token can do For instance:

READ, WRITE, DELETE or

SEND_SMS, SEND_MMS, GET_LOCATION, PAY


Refresh Tokens

APIs may return two tokens Access token with an expiration time Refresh token with no expiration time

Refresh token used to get a new access token

No additional user authentication is required


Why Refresh Tokens? What if the access token is compromised?

Harder to guess if it has an expiration time Harder to use a stolen token from a device

So why is the refresh token harder to steal?

It isn’t It’s still stored on the device or web server


OAuth in the World

20


Key Specs

There are many more specs – check the IETF process: http://tools.ietf.org/wg/oauth/

Spec Status Authorization Framework RFC6749 Bearer Token RFC6750 SAML Bearer Token RFC7522 JWT Bearer Token RFC7523 Dynamic Registration RFC7591 Introspection RFC7662 Revocation RFC7009 Secure POP RFC7636 HTTP Mac Tokens Expired


Some Big OAuth Users API OAuth Support Notes Facebook Almost 2.0 Authorization code for login; also supports login via SDK Twitter 1.0a Extensions named “xAuth” and “OAuth Echo” Salesforce 2.0 Supports JWT and SAML tokens as well as username/password PayPal 2.0 Also uses OpenID Connect and extra handshake Google 2.0 Browser used for all login

22


OpenID Connect

User authentication / SSO protocol

Layered on top of OAuth

Standardizes much of the complexity around the “authorization code” grant type

Standard ways for passing around user information

23


OAuth at Apigee

About half of Apigee Enterprise customers use OAuth 2.0 Slightly more use “API Keys” instead A few customers have OAuth 1.0a Many customers have neither:

“API Key” authentication only Username / password SSL, many other options

ThankstoAmitChakrabortyfromApigeeforthisdata


More Steps to OAuth

It’s not just about tokens How is the user authenticated?

Most Apigee customers use existing web pages or directory servers for user authentication How is consent granted to issue the token?

Usually done through the browser Many different ways to implement it

Thank you

oauth today - files.meetup.comfiles.meetup.com/17533002/oauth-slides-greg.pdf · for reference:...

Documents