Future Proofing the OAuth 2.0 Authorization Code Grant Protocol by the application of BCM Principles

Nomura Research Institute

#osw17

Future Proofing the OAuth 2.0 Authorization

Code Grant Protocol by the application of BCM

Principles

July 14, 2017

Nat Sakimura


© 2016 by Nomura Research Institute. All rights reserved.


Nat Sakimura

(Co-)Author of:

OpenID Connect Core 1.0

JSON Web Token [RFC7519]

JSON Web Signature [7515]

OAuth PKCE [RFC7636]

OAuth JAR [forthcoming]

Etc.

(Co-)Editor of:

ISO/IEC 29184 Guidelines for online notice and consent

ISO/IEC 29100 AMD: Privacy Framework

ISO/IEC 27551 Requirements for attribute based

unlinkable entity authentication

Etc.

• Research Fellow,


• Chairman of the Board,

OpenID Foundation

• Chair, Financial API WG

• Head of Japanese delegation to

ISO/IEC JTC 1/SC 27/WG5

• Liaison Officer SC 27/WG5 --

OECD/SPDE

• https://nat.Sakimura.org

• @_nat_en (English)

• @_nat (Japanese)

• Linked.in/natsakimura

• https://www.linkedin.co

m/in/natsakimura

• https://ja.wikipedia.org/

wiki/崎村夏彦

.. and an amateur flutist (https://youtu.be/3gTCQhTcXL0)

https://www.linkedin.com/in/natsakimura

https://ja.wikipedia.org/wiki/%E5%B4%8E%E6%9D%91%E5%A4%8F%E5%BD%A6

https://youtu.be/3gTCQhTcXL0



BCM PrinciplesP1 Positional tagging. Cryptographic

message components should contain

information that uniquely identities

their origin. In particular, the

information should identify the

protocol, the protocol variant, the

message number, and the particular

position within the message, from

which the component was sent.

P2 Inclusion of identities and their roles.

Each cryptographic message

component should include information

about the identities of all the agents

involved in the protocol run and their

roles, unless there is a compelling

reason to do otherwise.

3 Criteria

(a)Unique Source

Identifier

(b)Protocol + version +

msg identifier

(c)Full list of actor/roles

Basin, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798

Standard for Entity Authentication. Journal of Computer Security - Security and Trust

Principles archive Volume 21 Issue 6, 817-846 (2013)

(a)

(b)

(c)



Let’s apply!

4

Let’s Play!



RFC6749 OAuth – code grant protocol msgs

Authorization Request

Authorization Response

Token Request

Token Response

Assume:

a network attacker as (e.g. Browser malware)

the crypto & TLS are not broken

pure RFC6749 – Three parties static OAuth 2.0

5

UA

Clien

tAS



So, how is RFC6749 (Naïve implementation) doing?

Message Parameters (a) Unique

Source Identifier

(b) Protocol +

version identifier

(c) Full list of

actor/roles

Authorization

Request

response type

client id

redirect uri

scope

state

Authorization

Response

code

state

other extension

parameters

Token Request grant type

code

redirect uri

client

credential/client id

.

Token Response access token

token_type

expires_in

refresh_token

others

6

Combination of

parameters are unique

for each message type =

(b) Good!

Legend

Required Parameter

Optional Parameter

Recommended Parameter

But the good ends here.



So, how is RFC6749 (Naïve implementation) doing?


Source Identifier

(b) Protocol +

version identifier

(c) Full list of

actor/roles

Authorization

Request

response type

client id

redirect uri

scope

state

Client ID is not

globally unique.

Tampering

possible

List of params as

identifier, but it is

not integrity

protected

No.

Authorization

Response

code

state

other extension

parameters

No source

identifier

As above No


code

redirect uri

client


Client ID is not

globally unique.

OK (as long as

there is no OAuth

3.0)

No.


token_type

expires_in

refresh_token

others

No source

identifier

As above No.

7



8

It’s a sad

state.



Could be tightened up


Source Identifier

(b) Protocol +

version identifier

(c) Full list of

actor/roles

Authorization

Request

response type

client id

redirect uri

scope

state

Unique redirect

URI + Client ID

Request signing (a) + state as the

UA identifier /

TBID as UA

identifier

Authorization

Response

code

state

other extension

parameters

Unique redirect

URI

Response signing (a) + client_id +

state as the UA

identifier / TBID as

UA identifier


code

redirect uri

client


Unique redirect

URI + Client ID

OK (as long as

there is no OAuth

3.0)

(a) + state as the

UA identifier /

TBID as UA

identifier


token_type

expires_in

refresh_token

others

Unique redirect

URI

As above (a) + client_id +

state as the UA

identifier / TBID as

UA identifier

9



Integrity protect the AuthZ Request/Response

• draft-ietf-oauth-jwsreq aka OAuth JAR

AuthZ Request

• Use ID Token as a dethatched signature.

• Include new parameter `s_hash` in the ID Token.

AuthZ Response

10


Nomura Research InstituteComparisonMessage Original

Parameters

Modified Parameters Original Integrity

Protection

Modified Integrity

Protection

Authorization

Request

response type

client id

redirect uri

scope

state

response type

client id

redirect uri (uniqeue)

scope

state/tbid

None JAR

Authorization

Response

code

state

extension

params

code

state


client id

state/tbid

extension params

None ID Token + s_hash


code

redirect uri

client cred/id

grant type

code


client cred/id

state/tbid

TLS TLS


token_type

expires_in

refresh_token

others

access token

token_type

expires_in

refresh_token

others

TLS TLS

11



BCM Principles Satisfied!

12



13



14

Science

needed!

Future Proofing the OAuth 2.0 Authorization Code Grant Protocol by the application of BCM Principles

Technology

Transcript of Future Proofing the OAuth 2.0 Authorization Code Grant Protocol by the application of BCM Principles