Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC Deployment #api
4 likes5,184 views
This document discusses authorization architecture patterns for OAuth/OIDC deployment and avoiding pitfalls. It begins with an introduction to the speaker and their company Authlete, which provides an API authorization backend service. The document then covers OAuth/OIDC basics and common deployment patterns including having the authorization server embedded in the application runtime, as a separate IAM system, or integrated with API gateways. It argues that the semi-hosted pattern, where the authorization server frontend is separate from the backend, provides the most flexibility. Authlete is presented as an example semi-hosted authorization server solution.
![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%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%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](https://image.slidesharecdn.com/authorization-architecture-patterns-191010165538/85/Authorization-Architecture-Patterns-How-to-Avoid-Pitfalls-in-OAuth-OIDC-Deployment-api-27-320.jpg)
![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](https://image.slidesharecdn.com/authorization-architecture-patterns-191010165538/85/Authorization-Architecture-Patterns-How-to-Avoid-Pitfalls-in-OAuth-OIDC-Deployment-api-28-320.jpg)
![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%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%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](https://image.slidesharecdn.com/authorization-architecture-patterns-191010165538/85/Authorization-Architecture-Patterns-How-to-Avoid-Pitfalls-in-OAuth-OIDC-Deployment-api-29-320.jpg)
![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](https://image.slidesharecdn.com/authorization-architecture-patterns-191010165538/85/Authorization-Architecture-Patterns-How-to-Avoid-Pitfalls-in-OAuth-OIDC-Deployment-api-30-320.jpg)
![Hacking Web 2.0 - Defending Ajax and Web Services [HITB 2007 Dubai]](https://cdn.slidesharecdn.com/ss_thumbnails/hacking-web-20-defending-ajax-and-web-services-hitb-2007-dubai-25117-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Similar to Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC Deployment #api (20)
More from Tatsuo Kudo (20)
Recently uploaded (17)
Authorization Architecture Patterns: How to Avoid Pitfalls in #OAuth / #OIDC Deployment #api
- 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%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%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%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%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