rfc6749 et alia 20130504

66
The standard RFC6749

Upload: mattias-jidhage

Post on 06-May-2015

328 views

Category:

Technology


2 download

DESCRIPTION

Presentation of RFC6749 given at Omegapoint conference OPKoKo 13.1

TRANSCRIPT

Page 1: RFC6749 et alia 20130504

The standard RFC6749

Page 2: RFC6749 et alia 20130504
Page 3: RFC6749 et alia 20130504

Checkpoint

The problem

The history

Page 4: RFC6749 et alia 20130504
Page 5: RFC6749 et alia 20130504

1.1 Roles

resource owner resource server authorization server client @Override

protected AuthorizationCodeFlow initializeFlow() throws IOException …

Page 6: RFC6749 et alia 20130504

1.2 Flow Authorization Request

@O

verr

ide

pro

tect

ed A

utho

rizat

ionC

odeF

low

initi

aliz

eFlo

w()

th

row

s IO

Exc

eptio

n …

Authorization Grant

Authorization Grant

Access Token

Access Token

Protected Resource

Page 7: RFC6749 et alia 20130504

1.3 Authorization Grant

•  Four grant types – authorization code –  implicit –  resource owner password credentials – client credentials –  (extension grants…)

Page 8: RFC6749 et alia 20130504

1.4 Access Token

•  a string representing an authorization – usually opaque to the client

•  may denote an identifier used to retrieve the authorization information

•  may self-contain the authorization information in a verifiable manner

•  details in companion specifications

Page 9: RFC6749 et alia 20130504

1.5 Refresh Token

•  credentials used to obtain access tokens – when access token has expired –  long lived (forever and ever) – only sent to authorization server – denotes an identifier used to retrieve the

authorization information – OPTIONAL

Page 10: RFC6749 et alia 20130504

2.0 Client Registration

•  Needs to be done (client type, redirect URI, keys)

•  Details out-of-scope for RFC6749 – Manual – OAuth 2.0 Dynamic Client Registration

Protocol •  draft-ietf-oauth-dyn-reg-09

– OpenID Connect Dynamic Client Registration 1.0 - draft 08

Page 11: RFC6749 et alia 20130504

•  Real world examples – Google – Facebook – Twitter

2.0 Client Registration

Page 12: RFC6749 et alia 20130504

2.1 Client types

•  Confidential – web application

•  Public – user-agent-based application – native application

Page 13: RFC6749 et alia 20130504

2.2/3 Identifier & Auth

•  Client Identifier – client_id (string, not secret)

•  Client Authentication (confidential client type) – Basic Authentication (client_id:client_secret)

•  And – Other Authentication Methods – Unregistered

Page 14: RFC6749 et alia 20130504

3.0 Protocol Endpoints

•  authorization server endpoints (URL:s) – Authorization endpoint – Token endpoint

•  client endpoint – Redirection endpoint

•  resource server – As required…

Page 15: RFC6749 et alia 20130504

4.0 Obtaining Authorization

•  Our main target is getting an Access Token – There are a couple of ways to do it

•  depending on the client type

Page 16: RFC6749 et alia 20130504

4.1 Authorization Code Grant

Authorization Request

Authorization Grant

Authorization Grant

Access Token

Access Token

Protected Resource @override

Authentication

Page 17: RFC6749 et alia 20130504

4.2 Implicit Grant

Authorization Request

Access Token

Redirection URI

Script

Access Token

Protected Resource @override

Authentication

@override resource

Page 18: RFC6749 et alia 20130504

4.3 Resource Owner Password Credentials Grant

Authorization Grant

Access Token

Access Token

Protected Resource

@override

Page 19: RFC6749 et alia 20130504

4.4 Client Credentials Grant

Authorization Grant

Access Token

Access Token

Protected Resource

@override

Page 20: RFC6749 et alia 20130504

4.5 Extension Grants POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Asaml2- bearer&assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- ------ Example is OAuth-SAML2

Page 21: RFC6749 et alia 20130504

4.5 Extension Grants POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded grant_type=urn:ietf:params:oauth:grant-type:saml2-bearer &assertion=PEFzc2VydGlvbiBJc3N1ZUluc3RhbnQ9IjIwMTEtMDU [...omitted for brevity...]aG5TdGF0ZW1lbnQ-PC9Bc3NlcnRpb24- ------ Example is OAuth-SAML2

Page 22: RFC6749 et alia 20130504

5. Issuing an Access Token HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }

Page 23: RFC6749 et alia 20130504

5.1 Successful response •  access_token

–  REQUIRED

•  token_type –  REQUIRED

•  expires_in –  RECOMMENDED

•  refresh_token –  OPTIONAL

•  scope –  OPTIONAL/REQUIRED

Page 24: RFC6749 et alia 20130504

6.0 Refreshing an Access Token

POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded grant_type=refresh_token &refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

Page 25: RFC6749 et alia 20130504

7. Accessing Protected Resources

•  Present access token – How depends on token_type

•  Server validates (out of scope) – Generally interaction with Authorization Server

Page 26: RFC6749 et alia 20130504

7.1 Access Token Types

•  What type of token? – Compare with concept of grant_type

•  Not defined by OAuth2 – A registry is defined

•  Contents – Bearer (RFC6750) – Mac (Oauth-HTTP-MAC)

Page 27: RFC6749 et alia 20130504

Extensibility

•  Defining Access Token Types •  Defining New Endpoint Parameters •  Defining New Authorization Grant Types •  Defining New Authorization Endpoint

Response Type •  Defining Additional Error Codes

Page 28: RFC6749 et alia 20130504

Critiscism

•  Not that specified •  A consultants dream

Page 29: RFC6749 et alia 20130504

Related Standards

Page 30: RFC6749 et alia 20130504

‘oauth’ in ietf.org

Page 31: RFC6749 et alia 20130504

Bearer Token Usage

•  RFC6750 – Details on OAuth2 access_token – Defines token_type bearer (first)

•  “A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).”

Page 32: RFC6749 et alia 20130504

Bearer Token Usage

•  does not specify the encoding or the contents of the token??

•  Methods – Authorization Request Header Field – Form-Encoded Body Parameter – URI Query Parameter

Page 33: RFC6749 et alia 20130504

Mac Token

•  draft-ietf-oauth-v2-http-mac-03 – access_token

•  token_type = mac (second, not yet approved)

–  integrity

Page 34: RFC6749 et alia 20130504

OAuth Assertions Framework

•  draft-ietf-oauth-assertions-11 – Framework, needs instances

•  ietf-oauth-saml2-bearer •  ietf-oauth-jwt-bearer

Page 35: RFC6749 et alia 20130504

SAML2 Bearer Assertions

Authorization Grant

Access Token

Access Token

Protected Resource

@override

Page 36: RFC6749 et alia 20130504

SAML2 Bearer Assertion

•  Note: ‘Bearer’ now used to describe assertion on Authorization Grant – not Access Token

•  SAML2 Assertion – another possible grant_type

Page 37: RFC6749 et alia 20130504

JWT Bearer Tokens

Authorization Grant

Access Token

Access Token

Protected Resource

@override

Page 38: RFC6749 et alia 20130504

JWT Bearer Tokens

•  Similar to SAML2 •  grant_type: urn:ietf:params:oauth:grant-

type:jwt-bearer

Page 39: RFC6749 et alia 20130504

JWT Tokens

•  JSON Web Token (JWT) is a compact means of representing claims to be transferred between two parties. – JSW (JSON Web Signature) – JWE (JSON Web Encryption)

•  Enables MAC/signed/encrypted

Page 40: RFC6749 et alia 20130504

OpenID Connect

•  a simple identity layer on top of the OAuth 2.0 protocol.

•  allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server

Page 41: RFC6749 et alia 20130504

OpenID Connect: flow

•  Authorization Code Flow –  response_type = code id_token

•  Implicit Flow (RECOMMENDED) –  response_type = token id_token

Page 42: RFC6749 et alia 20130504

OpenID Connect: scope

•  openid - REQUIRED •  profile - OPTIONAL •  email - OPTIONAL •  address - OPTIONAL •  phone - OPTIONAL

Page 43: RFC6749 et alia 20130504

additions •  response_type: id_token •  endpoint: /check_id, /userinfo

•  id_token is returned •  send as access_token to /check_id •  control info returned

•  send access_token to /userinfo •  user_info is returned

Page 44: RFC6749 et alia 20130504

Recap Authorization Request

@O

verr

ide

pro

tect

ed A

utho

rizat

ionC

odeF

low

initi

aliz

eFlo

w()

th

row

s IO

Exc

eptio

n …

Authorization Grant

Authorization Grant

Access Token

Access Token

Protected Resource

Page 45: RFC6749 et alia 20130504

? Thank You! @mjidhage www.sakerhetspodcasten.se

Page 46: RFC6749 et alia 20130504

The actual problem

46

Lisa

Page 47: RFC6749 et alia 20130504

47

Information

Lisa

Page 48: RFC6749 et alia 20130504

48

Lisa

Page 49: RFC6749 et alia 20130504

49

Service Provider

Lisa

Page 50: RFC6749 et alia 20130504

50

Lisa

Page 51: RFC6749 et alia 20130504

51

Consumer

Lisa

Page 52: RFC6749 et alia 20130504

52

Lisa

Page 53: RFC6749 et alia 20130504

Why – the plot?

53

: Hmm, don’t know - could it be, [email protected]?

: h4pp1n3ss!

: Perfect! We’ll steal your paypal, twitter and facebook account through the hotmail account and print your photos right away. If we find any other interesting private photos while we are in there we’ll print them too for our personal viewing pleasure. fake

: Ok, great! What’s your password? fake

: Hi Lisa, what’s your username? fake

Page 54: RFC6749 et alia 20130504

54

How?

Authorization in 5 easy steps •  Intent •  Request Token •  Authorize Request Token •  Exchange Token •  Access Data

NB! Demo will follow

Page 55: RFC6749 et alia 20130504

55

: Hi, ! I would like to order printouts of some of my on , they are marked as private. Could you please print them?

: Sure, we just need to ask permission from

Step 1: Intent

Page 56: RFC6749 et alia 20130504

56

Hi ! This is speaking! Can I have a Request Token? HMAC-SHA1 (Yours Truly, Moo.)

: “Sure! Your Request Token is: 9iKot2y5UQTDlS2V and your secret is: 1Hv0pzNXMXdEfBd”

: Thanks!

Step 2: Request Token

Page 57: RFC6749 et alia 20130504

57

Step 3: Authorize Request Token

: Sure, just redirect my browser and I will be done in a second!

: Hi , could you please go to to authorize the Request Token:9iKot2y5UQTDlS2V? When you have made the authorization, I can fetch your .

Page 58: RFC6749 et alia 20130504

58

Step 3, Continued

: , I would like to authorize 9iKot2y5UQTDlS2V

: Sure - to be on the safe side; you are allowing to read your private pictures? We trust them, so there are no issues from our side.

: Yes, that is correct!

: Ok, good. Now get back too and tell them it is ok to proceed.

Page 59: RFC6749 et alia 20130504

59

Step 3, Optional Notify

: Hi , I just told that you are allowed to access my private pictures and they told me the pictures are ready for you to access them.

: Perfect, thank you!

Page 60: RFC6749 et alia 20130504

60

Step 4: Exchange Token

: Hi, . Could I exchange this token: 9iKot2y5UQTDlS2V for an Access Token? HMAC-SHA1 (Yours Truly, Moo.)

: Sure! Your Access Token is: 94S3sJVmuuxSPiZz and your Secret is: 4Fc8bwdKNGSM0iNe”

: Perfect, thank you!

Page 61: RFC6749 et alia 20130504

61

Step 5: Access Data

: Hi , I would like to fetch the private pictures owned by 94S3sJVmuuxSPiZz. HMAC-SHA1 (Yours Truly, Moo.)

: Here they are , anything else?

Page 62: RFC6749 et alia 20130504

62

Take Away

•  No information on the identity of Lisa is passed to Moo and Moo have no idea of what Lisas credentials on Flickr is.

•  => Not an authentication protocol/standard/technology

•  API independent –  there are lots of different implementations on both client and

server side

The Standard

Page 63: RFC6749 et alia 20130504

History

Page 64: RFC6749 et alia 20130504

64

�  2006-11 Blaine Cook, Twitter started working on Twitter’s OpenID implementation.

�  2007-04 A Google group started to write a draft protocol specification

�  2007-06 A first draft was ready and the group was opened for everyone interested in contributing to the specification

When?

t

Page 65: RFC6749 et alia 20130504

65

• 2007-12 Initial version OAuth 1.0 ready • mainly based on the Flickr Auth API and Google AuthSub • 2009-06 Revised version 1.0a due to a security flaw • http://oauth.net/core/1.0a

• 2010-04 RFC 5849 - IETF Informational RFC “The OAuth 1.0 Protocol” • OAuth 2.0 http://tools.ietf.org/html/draft-ietf-oauth-v2-31 • New protocol, not backward compatible with OAuth1

• Simplify and create a better user experience • Less secure due to no digital signature?

When?

t

Page 66: RFC6749 et alia 20130504

66 2011-05-06

The Standard