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)

BCM Principles
P1 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
t
AS

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

Comparison
Message 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

More Related Content

What's hot (13)

Similar to Future Proofing the OAuth 2.0 Authorization Code Grant Protocol by the application of BCM Principles (20)

More from Nat Sakimura (20)

Recently uploaded (20)

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