Sei sulla pagina 1di 38

PINGIDENTITY.

COM
OAUTH 101

Copyright © 2015 Ping Identity Corp. All rights reserved.2


BASIC PROBLEM
§ A web application wants to search your email
contacts

§ Do you give that app your email password?

§ What if you could give an application *limited*


access to your email?

Copyright © 2015 Ping Identity Corp. All rights reserved.3


OAUTH!
§ No sharing passwords
– Instead, give out a token

§ What if…
– You change your password?
› Token’s still valid
– That application gets hacked?
› Revoke the token

Copyright © 2015 Ping Identity Corp. All rights reserved.4


TOKENS ARE SAFE
OAuth tokens can be limited by:
– Scope: the app can only see your contacts
– Time: for the next hour
– Action: read-only – no editing abilities

Copyright © 2015 Ping Identity Corp. All rights reserved.5


OAUTH EXAMPLE
§ You want to buy from an
online music store, Tunes
Partner.
– You want to pay with your
bank, IDTel.
§ Tunes Partner
– Needs to charge bank
account
– Give out bank password?
No.
– OAuth token? Yes!

Copyright © 2015 Ping Identity Corp. All rights reserved.6


OAUTH EXAMPLE
§ Tunes Partner
redirects you to
IDTel

• IDTel asks you to authorize the


request:
• “Can Tunes Partner charge
your bank account $9.99?”

Copyright © 2015 Ping Identity Corp. All rights reserved.7


!
OAUTH EXAMPLE

§ You are sent back to the callback URL, the Tunes Partner
website
– In the background, Tunes Partner receives a token – “You’re authorized to
charge $9.99 to this IDTel account”
§ Tunes Partner never sees your IDTel password

Copyright © 2015 Ping Identity Corp. All rights reserved.8


BASIC TERMINOLOGY
§ Resource Owner (RO)
– Owns the resource
– (end user)
§ Client
– Application or server requesting
access to protected resources
– (Tunes Partner)
§ Resource Server (RS)
– Server where the actual protected
data is
– (ID Tel’s Main Server)
§ Authorization Server (AS)
– Server that gives out the tokens
– (ID Tel’s Authorization Server)
§ Service Provider (SP)
– The RS and AS together
– (ID Tel)

Copyright © 2015 Ping Identity Corp. All rights reserved.9


TOKEN TERMINOLOGY
§ Access Tokens
– The token (credential used by client to access protected resources at the RS)
– Issued by the Authorization Server
– “I’m Tunes Partner and I’m allowed to charge you $10”
§ Refresh Tokens
– Used by client to obtain a new access token when the old one expires
– “I’m Tunes Partner and I’m allowed to charge you $10 next month, too”
§ Authorization Codes
– Used to trade for access tokens
– “Do you want to give Tunes Partner permission to charge your bank account $10?”

Copyright © 2015 Ping Identity Corp. All rights reserved.10


MORE TERMINOLOGY!
§ Client Id
– A value used by the Client to identify itself to the Service
Provider
– “I’m Tunes Partner”

§ Client Secret
– A secret used by the Client to establish ownership of the
Client ID
– “Here’s proof”

Copyright © 2015 Ping Identity Corp. All rights reserved.11


JUST SO WE’RE CLEAR…

IDTel

1) “I want to buy this


song!”

Resource Owner - User Client – Tunes Partner


Copyright © 2015 Ping Identity Corp. All rights reserved.12
JUST SO WE’RE CLEAR…

IDTel

1) “I want to buy this song!”


2) Okay, let me redirect you to your bank

Resource Owner - User Client – Tunes Partner


Copyright © 2015 Ping Identity Corp. All rights reserved.13
JUST SO WE’RE CLEAR…

IDTel

3) “Please ask
the user if I,
Tunes
Partner, can
charge her $1
for this song.”

1) “I want to buy this song!”


2) Okay, let me redirect you to your bank

Resource Owner - User Client – Tunes Partner


Copyright © 2015 Ping Identity Corp. All rights reserved.14
JUST SO WE’RE CLEAR…

IDTel

3) “Please ask
the user if I,
Tunes 4) Please log in;
Partner, can can Tunes
charge her $1 Partner charge
for this song.” you $1? If yes,
I’ll send them an
authorization
code.
1) “I want to buy this song!”
2) Okay, let me redirect you to your bank

Resource Owner - User Client – Tunes Partner


Copyright © 2015 Ping Identity Corp. All rights reserved.15
JUST SO WE’RE CLEAR…

IDTel

3) “Please ask
the user if I,
Tunes 4) Please log in;
Partner, can can Tunes
charge her $1 Partner charge
for this song.” you $1? If yes,
I’ll send them an
authorization
code.
1) “I want to buy this song!”
2) Okay, let me redirect you to your bank

Resource Owner - User 5) Authorization Code from AS: Client – Tunes Partner
“Tunes Partner can charge user $1”
Copyright © 2015 Ping Identity Corp. All rights reserved.16
JUST SO WE’RE CLEAR…

IDTel

3) “Please ask
the user if I, 6) I have an
Tunes authorization code
Partner, can 4) Please log in; that says Tunes
charge her $1 can Tunes Partner can charge
for this song.” Partner charge $1. I’m Tunes Partner
you $1? If yes, – here’s my client
I’ll send them an secret. Give me an
authorization access token.
code.
1) “I want to buy this song!”
2) Okay, let me redirect you to your bank

Resource Owner - User 5) Authorization Code from AS: Client – Tunes Partner
“Tunes Partner can charge user $1”
Copyright © 2015 Ping Identity Corp. All rights reserved.17
JUST SO WE’RE CLEAR…

IDTel

3) “Please ask
the user if I, 6) I have an 7) Hi Bank! I have
Tunes authorization code an access token
Partner, can 4) Please log in; that says Tunes saying I’m allowed
charge her $1 can Tunes Partner can charge to charge the user
for this song.” Partner charge $1. I’m Tunes Partner $1; here it is, go
you $1? If yes, – here’s my client charge her $1.
I’ll send them an secret. Give me an
authorization access token.
code.
1) “I want to buy this song!”
2) Okay, let me redirect you to your bank

Resource Owner - User 5) Authorization Code from AS: Client – Tunes Partner
“Tunes Partner can charge user ©$1”
Copyright 2015 Ping Identity Corp. All rights reserved.18
HALFWAY!
§ OAuth
– An open protocol standard for Web API authorization
– Provides a method for users to grant third-party access to
their resources without sharing their passwords
§ Tokens can be limited by:
– Scope
– Time
– Action

Copyright © 2015 Ping Identity Corp. All rights reserved.19


OAUTH PURPOSES…
§ Use cases:
– Password antipattern
– Secure cloud APIs
– Secure native mobile apps

§ End goal:
– Client gets and uses access token

Copyright © 2015 Ping Identity Corp. All rights reserved.20


OAUTH USE CASE FLOW

Authorization
1. Get access token Server

Client
2. Use access token API
(Resource Server)

Copyright © 2015 Ping Identity Corp. All rights reserved.


GRANT TYPES – GETTING AN ACCESS TOKEN

§ Authorization Code
– Use case: Web-server apps (and native apps)
§ Implicit
– Use case: Browser-based apps
§ Resource Owner Password Credentials
– Use case: Native mobile apps (for backwards compatibility)
§ Client Credentials
– Use case: Server-Server

Copyright © 2015 Ping Identity Corp. All rights reserved.22


GRANT TYPE: AUTHORIZATION CODE
§ Use case:
– Generally, web applications
– Tunes Partner website

Copyright © 2015 Ping Identity Corp. All rights reserved.23


GRANT TYPE: AUTHORIZATION CODE FLOW

• “Traditional” applications running on a web server


• Tunes Partner web app
• Get access token by trading authorization code

Authorization Server

Web Application Resource Server


Resource Owner

Copyright © 2015 Ping Identity Corp. All rights reserved. 24


AUTHORIZATION CODE GRANT GENERAL
FLOW
1. Client redirects user to the
authorization server
(Tunes Partner website to IDTel’s
1. Client ID, scope PingFederate)
2. User Authenticates 2. User authenticates, then authorizes the
Authorization request.
3. Authorization Code Server - IDTel (Yes, Tunes Partner can charge me $10)

1 3 3. Authorization server redirects user


back to web app with an authorization
code
4. Client Secret, Auth Code
4. Client sends authorization code to
5. Access Token (w/ optional Refresh Token) Authorization server with client secret

Client – Tunes 5. Authorization server returns the access


Partner token

Copyright © 2015 Ping Identity Corp. All rights reserved. 25


GRANT: IMPLICIT
§ Application that runs in the browser, typically JavaScript or
‘widget’ clients
– Tunes Partner Widget
§ No client secret or authorization code

Website hosting Client


Authorization Server

Resource Server

Resource Owner
Copyright © 2015 Ping Identity Corp. All rights reserved. 26
IMPLICIT GRANT GENERAL FLOW
1. Browser application
redirects user to
1. Client ID, Scope authorization server

2. User Authenticates
Authorization 2. User authenticates, then
3. Access token in URL Server - IDTel (hopefully!) authorizes the
request.
1 3
(Yes, charge me $10)

3. Authorization Server
redirects user back to web
app with the access token
Client – embedded in the query
Tunes Partner string.
Widget

Copyright © 2015 Ping Identity Corp. All rights reserved. 27


GRANT TYPE: RESOURCE OWNER
PASSWORD CREDENTIAL
§ An installed application on a phone or tablet
– Mobile bank application

§ No third party client


Authorization Server

Native Client

Resource Server

Resource Owner

Copyright © 2015 Ping Identity Corp. All rights reserved. 28


RESOURCE OWNER PASSWORD
GRANT FLOW 1. Mobile application
collects user
password and sends
1 – User Credentials and Client Secret to authorization
server in request for
Authorization access token
Server - IDTel

2. Authorization Server
returns access token
to mobile
2 – Access Token (w/ optional Refresh Token)
application

Client –
IDTel mobile
app

Copyright © 2015 Ping Identity Corp. All rights reserved. 29


GRANT TYPE: CLIENT CREDENTIALS
§ Application to application
§ No specific user
§ Trades client credentials for access token
Authorization Server
Website hosting Client

Resource Server

Copyright © 2015 Ping Identity Corp. All rights reserved. 30


CLIENT CREDENTIALS GRANT FLOW
1. Client application
sends its own
Authorization credentials to
Server - IDTel authorization server
in request for access
token

2. Authorization
1 – Client Credentials
Server returns
access token to
2 – Access Token
client server
Client –
Remote server
or application

Copyright © 2015 Ping Identity Corp. All rights reserved. 31


REFRESH TOKEN
§ Need a new access token
§ In grants:
– Authorization code
– Resource owner password credentials

Copyright © 2015 Ping Identity Corp. All rights reserved. 32


REFRESH TOKEN GRANT FLOW

1. Client application
sends its own
credentials and
Authorization refresh token to
Server - IDTel PingFederate in
request for access
token

2. PingFederate
1. Client Credentials & Refresh token
returns access token
2. Access Token

Client
(tunes partner
website or IDTel
mobile app)
Copyright © 2015 Ping Identity Corp. All rights reserved. 33
GRANT TYPES
Grant Type What You Need How You Authenticate User

Authorization Code End-user Web browser redirect


- Use case: Web Applications credentials
App credentials
Implicit Grant End-user Web browser redirect optimized
- Use case: in-browser JS apps credentials for script-heavy apps
or ‘widget’ clients

Resource Owner Password End-user Send username/password in API


Credentials credentials call
- Use case: Native Mobile App credentials
Apps
Client Credentials App credentials N/A
- Use case: Server apps

Copyright © 2015 Ping Identity Corp. All rights reserved.34


WHERE DID ALL OF THIS COME FROM?
§ In 2007, four problems were recognized
– Password anti-pattern
– Lack of standards & support of RESTful APIs
› Nothing comparable to WS-Security or WS-Trust
› Mishmash of HTTP Basic, HTTP Digest, proprietary mechanisms,
and mutual SSL for client authentication & trust
› Native mobile apps needed to be secure
› Cloud APIs needed to be secure

Copyright © 2015 Ping Identity Corp. All rights reserved.35


ENTER THE OAUTH HEROES!
§ Collaboration effort from many proprietary authorization solutions
– Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr API, AWS API, and more

OAuth 1.0a OAuth 2.0


• Released June 2009 • Released Dec 2010 from IETF
• Requires applications to use cryptographic • Signatures are now optional!
signature (big learning curve) • Requires SSL
• Web applications • Web apps
• JS/widget apps
• Native/Mobile apps
• server-server
• Resource server issues and verifies every token • Split Authorization Server and Resource Server

Copyright © 2015 Ping Identity Corp. All rights reserved.36


SECTION REVIEW
§ Should I use OAuth?
– Yes!

§ Twitter is using OAuth 1.0a


§ Google, Foursquare, Facebook, Windows Live,
Salesforce, GitHub, Geoloqi, etc… are all using
some revision of OAuth 2.0

Copyright © 2015 Ping Identity Corp. All rights reserved.37


PINGIDENTITY.COM

Potrebbero piacerti anche