Authorization Architecture Patterns: How to Avoid Pitfalls in … · 2019-10-28 · implement OAuth 2.0, OpenID Connect, Financial-grade API and CIBA. ... • OAuth / OpenID Connect

Authorization Architecture Patterns: How to

Avoid Pitfalls in OAuth/OIDC Deployment

Tatsuo Kudo

Authlete, Inc.

About Me

• Tatsuo Kudo https://www.linkedin.com/in/tatsuokudo

– Sun Microsystems (1998-2008)

– Nomura Research Institute (2008-2018)

– OpenID Foundation Japan (2013-2014)

– NRI SecureTechnologies (2014-2018)

– Authlete (2018-)

• VP of Solution Strategy

2

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

• A Tokyo / London based company

providing “API Authorization

Backend-as-a-Service” enabling

developers to quickly and securely

implement OAuth 2.0, OpenID

Connect, Financial-grade API and

CIBA.

https://www.authlete.com/

Who is Authlete?

3


4

• OAuth / OpenID Connect (OIDC) basics

• Deployment architecture patterns in the wild

• Future-proof API authorization services

In This Talk

OAuth / OIDC Basics

6

• Client credentials e.g. API Key (and API secret)

– Simple but not scalable

How API Servers Grant Access for Clients

1. API request with

client credentials

API Client API Server 2. API response

GET /items/12345 HTTP/1.1 x-api-key: <API Key>

7

• Tokens in exchange for client credentials

– More flexible but limited to client-server authentication


3. API request with token


Authorization

Server (AS) 1. Token request with

client credentials

2. Token

response

GET /items/12345 HTTP/1.1 Authorization: Bearer <Token>

POST /token HTTP/1.1 Authorization: Basic <Key:Secret>

8

• Tokens in exchange for authorization proof

– Resource owner / assertion issuer can participate access granting process


5. API request with token


1. Authorization /

assertion request

Resource Owner

/ Assertion Issuer

Authorization

Server (AS) 3. Token request with

authorization code /

assertion

2. Authorization

code / assertion

4. Token

response

User

Organization

HTTP/1.1 302 Found Location: https://as/authorize?...

(User authentication and consent)

GET /items/12345 HTTP/1.1 Authorization: Bearer <Token>

9

• Framework for API access delegation using tokens

– RFC 6749 describes token granting process and essential grant flows such as

authorization code and client credentials

• Highly extensible for broad use cases

– Extensible grant type

– User-involved (with user agents) and unattended (service accounts for machines)

• Sister standard: OpenID Connect

– “ID Token” to convey user authentication event

from Identity Provider to Relying Party

OAuth at a Glance

• Resource Owner

e.g. end user

• User Agent

e.g. Web browser

• Client

e.g. Web application using APIs

• Authorization Server

e.g. user authentication server

• Resource Server

e.g. API server

“OAuth Dance”

Resource

Owner User Agent Client

Authorization

Server

Resource

Server

10

Basic OAuth/OIDC

Authorization Code Grant Flow / Bearer Token

Resource


Authorization

Server

Resource

Server

（(Start)）

Authorization request

Authorization response

Token

request

Token

response

API request

API

response

（End）

User

authentication

and consent

Authorization

Request

Authorization

Code

Authorization

Code

Access

Token

Access

Token

API Response

• Receive Authorization Request

and return Authorization Code

• Receive Authorization Code

and return Access Token

• Receive API Request with

Access Token and return

API response

11

Advanced OAuth/OIDC for High-Stakes Transactions

FAPI (Financial-grade API)

12 https://www.authlete.com/fapi

Fintechs

Adversaries

Banks Authorization / token request

Authorization / token response

API requests with the token

Preventing fraudulent token

exchange by signing requests

and responses

Token theft

Preventing fraudulent access

by using mutual TLS to detect

identity of the requester

Stolen tokens won’t work as

the adversaries can’t use the

signing certificate bound to

these tokens

https://www.authlete.com/fapi

Advanced OAuth/OIDC for “Decoupled Authentication”

CIBA (Client Initiated Backchannel Authentication)

https://www.authlete.com/ciba 13

Send $50 to Bob

Alice

Alice’s smartphone

Notify to the bank’s app

Alice’s smart speaker

Initiate a payment via pre-registered bank’s APIs

Banking APIs with CIBA

Use case 1: Voice-initiated money transfer

Send Bob

$50 ?

Alice

Alice’s smartphone

Notify to the payment app

Teleshopping’s call center

Initiate a payment via pre-registered payment service’s APIs

Payment’s APIs with CIBA

Use case 2: Call-center-initiated payment

Buy ?

$50

$50

https://www.authlete.com/ciba_pr/

14

• Handmade OAuth server was valid in the

good old days (circa early 2010’s)

• It is no longer applicable nowadays

– A lot of OAuth extensions are now emerging

• Assertion framework, PKCE, JWT client

authentication, device grant, …

– Security considerations are frequently being

updated for new use cases and threats

• Mobile app ecosystem, microservices, high-

stakes transactions, …

Building Authorization Servers From Scratch

Source: https://twitter.com/blhjelm/status/1055551254401736704,

https://hackerone.com/hacktivity?order_direction=DESC&order_field=latest_disclosable_activity_at&filter=type%3Aall&querystring=oauth

https://twitter.com/blhjelm/status/1055551254401736704

https://hackerone.com/hacktivity?order_direction=DESC&order_field=latest_disclosable_activity_at&filter=type:all&querystring=oauth



15

• Identity and access

management (IAM)

• API management

(e.g. API gateways)

• Authorization

decision service

that decides “who has

access to what in which

context” for token

requests

Services Integrated with Authorization Server

Client Protected

Resources

Resource

Owner

Authorization

Server

IAM Service

Authorization

Decision Service

API Gateway

User

authentication

and consent

Token

request

API

request

Token

introspection

Deployment Architecture Patterns in the Wild

17

• Authorization server provides at least two

functionalities

– Protocol operations (OAuth, OIDC and their extensions)

– Token management (life cycle, clients, scopes etc.)

• Authorization server would often be a part of other

system

– Application runtime

– IAM system

– API gateways

Where Authorization Server Belongs

Authorization Server

Protocol

Operations

Token

Management

18

• Pros

– Application developers

don’t need to handle

OAuth

• Cons

– Runtime vendors

usually don’t consider

OAuth functionality with

high priority; sometimes

obsolete

AS Embedded in Application Runtime

Client Applications

Resource

Owner

Authorization

Server

Subsystem

IAM Service

Authorization

Decision

Implementation

API Endpoints

Application Runtime

User

authentication

and consent

Token

request

API

request

IAM System

19

• Pros

– Usually IAM vendors are

serious (and competing) in

adopting open standards

• Cons

– User management and

authentication services are

tightly integrated with AS

– Authorization decision

needs to be implemented

on the vendor’s proprietary

extension framework

AS Separated as IAM System

Client Protected

Resources

Resource

Owner

Authorization

Server

Subsystem

User

Authentication

Subsystem

Authorization

Decision

Subsystem

API Gateway

User

authentication

and consent

Token

request

API

request

Token

introspection

20

• Pros

– Familiar with API operations

• Cons

– API gateway vendors

usually don’t consider

OAuth functionality with high

priority; sometimes obsolete

– Authorization decision

needs to be implemented on

the vendor’s proprietary

extension framework

AS Integrated with API Gateways

Client Protected

Resources

Resource

Owner

Authorization

Server

Subsystem

IAM Service

Authorization

Decision

Subsystem

API Endpoint

Subsystem

API Gateway

User

authentication

and consent

Token

request

API

request

21

• Freedom of choice for

development

• Offloading cumbersome

protocol operations and

token management

• Leveraging the most

suited solutions and/or

other subsystems within

organizations

What Developers Really Needed

Client Protected

Resources

Resource

Owner

Authorization

Server

IAM Service

Authorization

Decision Service

API Gateway

Future-Proof API Authorization Services

23

• Deploying a “backend”

behind your authorization

server

• Your authorization server

acting as “frontend”

• No need to consider

“what to do next with

what methods” on

OAuth/OIDC protocol

processing

Introducing Semi-hosted Pattern

Client Protected

Resources

Resource

Owner

Authorization

Server

Frontend

IAM Service

Authorization

Decision Service

API Gateway

Authorization

Server

Backend User

authentication

and consent

Token

request

API

request

Token

introspection

Solution Example: Authlete Semi-Hosted Authorization Server Solution

24

Authlete Customer’s Environment API Clients

Existing Services

© 2018 Authlete, Inc.

Websites

Mobile

Networked

Devices


Authorization Decision

User

Authentication

Consent

Management

Entitlement

Management

API Servers / Gateways

/data /function /transaction

Authlete

Auth

oriz

atio

n

Backend A

PIs

Authorization

Information

(e.g. Tokens)

Database

Authorization Request

API Access Authorization Status

Check

OAuth/OIDC Processing Request

Authorization

Frontend

Leveraging

existing services Authorization decision logic with

no dependency on Authlete

Separation of operation

between authorization

server and API servers

Externalizing cumbersome

OAuth/OIDC processing

and token management

/…

OSS components

available via GitHub

Sequence is Simple - Implementation is Not

25

Resource


Authorization

Server

Resource

Server Processing Authorization Request

Issuing Authorization Code

Processing Token Request

Access Token Introspection

（(Start)）



Token

request

Token

response

API request

API

response

（End）

User

authentication

and consent

Offloading These Tasks to Authlete

Resource


Authorization

Server

Resource

Server Authlete API

Processing

Authorization

Request

Issuing

Authorization

Code

Processing Token

Request

Access

Token

Intro-

spection

/auth/authorization POST

/auth/authorization/issue POST

/auth/token POST

/auth/introspection POST

(Start)

Authorization

request

Authorization

response

Token

request

Token

response API

request

API

response （End）

User

authentication

and consent

26

1. Processing Authorization Request

Resource


Authorization

Server

Resource

Server Authlete

Authlete

{ "parameters":

"response_type=code&client_id=57297408867&red

irect_uri=https%3A%2F%2Fapi.authlete.com%2Fap

i%2Fmock%2Fredirection%2F10167240235" }'

Send query parameters “as is”

to Authlete

/auth/authorization POST

Authlete

{

"action": "INTERACTION",

"client": {

(OAuth Client information）

},

"service": {

(Authlete Service information）

},

"ticket":

"c4iy3TWGn74UMO7ihRl0ZS8OEUzV9axBlBbJbqxH-9Q"

[…]

}

Return a ticket and information

for authentication and consent

（(Start)）



Token

request

Token

response

API request

API

response

（End）

User

authentication

and consent

Processing

Authorization

Request

27

2. Issuing Authorization Code

Resource


Authorization

Server

Resource

Server Authlete

Authlete

{

"ticket": "FFgB9gwb_WXh6g1u-UQ8ZI-d_k4B-o-

cm7RkVzI8Vnc",

"subject": "78yM7DpDNgUTF7h4”

}

Send the ticket and frontend-

generated user identifier

/auth/authorization/issue POST

Authlete

{

"action": "LOCATION",

"responseContent":

"https://api.authlete.com/api/mock/redirectio

n/10167240235?code=_VSzpgug3OpdUymcbLYJjH1v9t

E4hSPaxX_pSkxUUyk"

[…]

}

Return response content to be

sent back to the client

（(Start)）



Token

request

Token

response

API request

API

response

（End）

User

authentication

and consent Issuing

Authorization

Code and Tokens

28

3. Processing Token Request

Resource


Authorization

Server

Resource

Server Authlete

Authlete

{ "parameters":

"grant_type=authorization_code&code=DkKMvKzrR

AsWErsWCChNX_gydqqgA55AW2OJlXmNTQI&redirect_u

ri=https%3A%2F%2Fapi.authlete.com%2Fapi%2Fmoc

k%2Fredirection%2F10167240235",

"clientId": 57297408867,

"clientSecret": "[…]", […] }

Send query parameters “as is”

to Authlete

/auth/token POST

Authlete

{

"responseContent":

"{\"scope\":null,\"expires_in\":86400,\"token

_type\":\"Bearer\",\"refresh_token\":\"sdQqY9

Tbhsq6ZsWm1rZLgW4A3yxIk6RcgmmexHZ9BXB\",\"acc

ess_token\":\"rt5bUJsGfS17YCSmYGtgelMtokTLdoC

mBe4VUFCk1YZ\"}",

[…]

}

Return response content to be

sent back to the client

（(Start)）



Token

request

Token

response

API request

API

response

（End）

User

authentication

and consent

Processing Token

Request

29

4. Access Token Introspection

Resource


Authorization

Server

Resource

Server Authlete

Authlete { "token": "VFGsNK-

5sXiqterdaR7b5QbRX9VTwVCQB87jbr2_xAI" }

Send a token for introspection

/auth/introspection POST

Authlete

{

"type": "introspectionResponse",

"resultCode": "A056001",

"resultMessage": "[A056001] The access

token is valid.",

"action": "OK",

"clientId": 57297408867,

"clientIdAliasUsed": false,

"existent": true,

"expiresAt": 1511252965000,

"refreshable": true,

"responseContent": "Bearer

error=\"invalid_request\"",

"subject": "78yM7DpDNgUTF7h4",

"sufficient": true,

"usable": true

}

Return details associated with

the token

（(Start)）



Token

request

Token

response

API request

API

response

（End）

User

authentication

and consent

Access

Token

Intro-

spection

30

• They have been using Authlete instead

of Azure API Management’s built-in

OAuth 2.0

– It didn’t meet their requirement for open

banking APIs

• They haven’t deployed any IAM for the

API infrastructure

– Their existing internet banking system does

user authentication and consent as well as

entitlement management

Semi-Hosted Pattern in Action: Seven Bank

Sources for the diagrams: https://www.isid.co.jp/case/case/2018sevenbank.html,

https://www.isid.co.jp/news/release/2018/0919.html

Background Seven Bank (SB) is a Japanese bank with c.a. 1.9M customers. It had planned to open its banking APIs and had decided to use Microsoft Azure PaaS to achieve it time- and cost-efficiently

Challenges Microsoft Azure did not provide API authorization functions that can satisfy the specification for the banking APIs

Solution Authlete could satisfy the specification for both read-only and read/write scenarios, and enabled them to build a new authorization server with Authlete APIs in a month

Benefit Achieved faster implementation of banking APIs just within 3 months

Easier to adopt new standards including Financial-grade API

Client (Bank

App and

Third-Party

Providers)

Other Apps

Bank

Customers

Authorization

Server

Frontend

Internet Banking

System

Authorization

Decision

Service

API Management

Authlete

Microsoft Azure

User

authentication

and consent

API

request

Token

request

31

https://www.isid.co.jp/case/case/2018sevenbank.html

https://www.isid.co.jp/news/release/2018/0919.html

Takeaways

33

• Examine which pattern is the best for

your context

– Application runtime if API authorization

doesn’t matter

– IAM system if you want to make AS tightly

coupled with user authentication service

– API gateways if you want build everything

on those infrastructure

• If none of options above works for you,

do consider semi-hosted pattern

– Take back the right to implement your own

authorization servers

Build a Future-Proof Authorization Server


FRONTEND

Authlete API

BACKEND

Semi-hosted Architecture

- Token management

- OAuth/OIDC protocol processing

- UI/UX

- Authorization decision logic

- Identity & access management

34

• Justin Richer (@justin__richer)’s blog entry

on semi-hosted service

– https://link.medium.com/SPXhiVMfz0

• Taka Kawasaki (@darutk)’s blog entry

on its implementation

– https://link.medium.com/ROV8nUTfz0

• Authlete

– https://www.authlete.com/

Resources

https://twitter.com/justin__richer

https://link.medium.com/SPXhiVMfz0

https://twitter.com/darutk

https://link.medium.com/ROV8nUTfz0


Thank You

www.authlete.com

www.linkedin.com/in/tatsuokudo

http://www.authlete.com/

Documents

Authorization Architecture Patterns: How to Avoid Pitfalls in … · 2019-10-28 · implement OAuth 2.0, OpenID Connect, Financial-grade API and CIBA. ... • OAuth / OpenID Connect