1. Authorization Architecture Patterns: How to
Avoid Pitfalls in OAuth/OIDC Deployment
Tatsuo Kudo
Authlete, Inc.

2. 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

3. • 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. 4
• OAuth / OpenID Connect (OIDC) basics
• Deployment architecture patterns in the wild
• Future-proof API authorization services
In This Talk

5. OAuth / OIDC Basics

6. 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. 7
• Tokens in exchange for client credentials
– More flexible but limited to client-server authentication
How API Servers Grant Access for Clients
3. API request with token
API Client API Server
4. API response
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. 8
• Tokens in exchange for authorization proof
– Resource owner / assertion issuer can participate access granting process
How API Servers Grant Access for Clients
5. API request with token
API Client API Server
6. API response
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. 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

10. • 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

11. Basic OAuth/OIDC
Authorization Code Grant Flow / Bearer Token
Resource
Owner
User Agent Client
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
• ReceiveAuthorization Request
and return Authorization Code
• ReceiveAuthorization Code
and return Access Token
• ReceiveAPI Request with
Access Token and return
API response
11

12. Advanced OAuth/OIDC for High-StakesTransactions
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

13. 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

14. 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
• Assertionframework, 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

15. 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
DecisionService
API Gateway
User
authentication
and consent
Token
request
API
request
Token
introspection

16. Deployment Architecture Patterns in the Wild

17. 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. 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

19. 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. 20
• Pros
– Familiar with API operations
• Cons
– API gateway vendors
usually don’t consider
OAuth functionality with high
priority; sometimesobsolete
– 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. 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
DecisionService
API Gateway

22. Future-Proof API Authorization Services

23. 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
DecisionService
API Gateway
Authorization
Server
Backend
User
authentication
and consent
Token
request
API
request
Token
introspection

24. Solution Example: Authlete
Semi-Hosted Authorization Server Solution
24
Authlete Customer’s EnvironmentAPI Clients
Existing Services
© 2018 Authlete, Inc.
Websites
Mobile
Networked
Devices
Authorization Server
Authorization Decision
User
Authentication
Consent
Management
Entitlement
Management
API Servers / Gateways
/data /f unction /transaction
Authlete
Authorization
BackendAPIs
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

25. Sequence is Simple - Implementation is Not
25
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
Processing Authorization Request
Issuing Authorization Code
Processing Token Request
Access Token Introspection
（(Start)）
Authorization request
Authorization response
Token
request
Token
response
API request
API
response
（End）
User
authentication
and consent

26. Offloading These Tasks to Authlete
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
Authlete API
Processing
Authorization
Request
Issuing
Authorization
Code
Processing Token
Request
Access
Token
Intro-
spection
/auth/authorizationPOST
/auth/authorization/issuePOST
/auth/tokenPOST
/auth/introspectionPOST
(Start)
Authorization
request
Authorization
response
Token
request
Token
response
API
request
API
response
（End）
User
authentication
and consent
26

27. 1. Processing Authorization Request
Resource
Owner
User Agent Client
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/authorizationPOST
Authlete
{
"action": "INTERACTION",
"client": {
(OAuth Client information）
},
"service": {
(Authlete Service information）
},
"ticket":
"c4iy3TWGn74UMO7ihRl0ZS8OEUzV9axBlBbJbqxH-9Q"
[…]
}
Return a ticket and information
for authentication and consent
（(Start)）
Authorization request
Authorization response
Token
request
Token
response
API request
API
response
（End）
User
authentication
and consent
Processing
Authorization
Request
27

28. 2. Issuing Authorization Code
Resource
Owner
User Agent Client
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/issuePOST
Authlete
{
"action": "LOCATION",
"responseContent":
"https://api.authlete.com/api/mock/redirectio
n/10167240235?code=_VSzpgug3OpdUymcbLYJjH1v9t
E4hSPaxX_pSkxUUyk"
[…]
}
Return response contentto be
sent back to the client
（(Start)）
Authorization request
Authorization response
Token
request
Token
response
API request
API
response
（End）
User
authentication
and consent
Issuing
Authorization
Code and Tokens
28

29. 3. Processing Token Request
Resource
Owner
User Agent Client
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/tokenPOST
Authlete
{
"responseContent":
"{¥"scope¥":null,¥"expires_in¥":86400,¥"token
_type¥":¥"Bearer¥",¥"refresh_token¥":¥"sdQqY9
Tbhsq6ZsWm1rZLgW4A3yxIk6RcgmmexHZ9BXB¥",¥"acc
ess_token¥":¥"rt5bUJsGfS17YCSmYGtgelMtokTLdoC
mBe4VUFCk1YZ¥"}",
[…]
}
Return response contentto be
sent back to the client
（(Start)）
Authorization request
Authorization response
Token
request
Token
response
API request
API
response
（End）
User
authentication
and consent
Processing Token
Request
29

30. 4. Access Token Introspection
Resource
Owner
User Agent Client
Authorization
Server
Resource
Server
Authlete
Authlete
{ "token": "VFGsNK-
5sXiqterdaR7b5QbRX9VTwVCQB87jbr2_xAI" }
Send a token for introspection
/auth/introspectionPOST
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)）
Authorization request
Authorization response
Token
request
Token
response
API request
API
response
（End）
User
authentication
and consent
Access
Token
Intro-
spection
30

31. • 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.isi d.co.j p/case/case/2018sevenbank.html,
https://www.isid.co.j p/news/release/2018/0919.html
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

32. Takeaways

33. 33
• Examine which pattern is the best for
your context
– Application runtime if API authorization
doesn’tmatter
– IAM system if you want to make AS tightly
coupled with user authentication service
– API gatewaysif 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 implementyour own
authorization servers
Build a Future-Proof Authorization Server
Authorization
Server
FRONTEND
Authlete
API
BACKEND
Semi-hostedArchitecture
- Token management
- OAuth/OIDC
protocol processing
- UI/UX
- Authorization
decision logic
- Identity & access
management

34. 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

35. Thank You
www.authlete.com
www.linkedin.com/in/tatsuokudo