authorization architecture patterns: how to avoid pitfalls in … · 2019-10-28 · implement oauth...
Post on 26-May-2020
21 Views
Preview:
TRANSCRIPT
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
• 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
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
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
• 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
• 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
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
• 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
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
• 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
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
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
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 Server
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
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
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/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
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/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))
Authorization request
Authorization response
Token
request
Token
response
API request
API
response
(End)
User
authentication
and consent
Processing
Authorization
Request
27
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/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))
Authorization request
Authorization response
Token
request
Token
response
API request
API
response
(End)
User
authentication
and consent Issuing
Authorization
Code and Tokens
28
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/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))
Authorization request
Authorization response
Token
request
Token
response
API request
API
response
(End)
User
authentication
and consent
Processing Token
Request
29
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/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))
Authorization request
Authorization response
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
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
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
top related