Why Assertion-based Access Token is preferred to Handle-based one?
Download as PPTX, PDF0 likes202 views
This document discusses the differences between assertion-based access tokens and handle-based access tokens in OAuth 2.0. Assertion-based tokens are parsable tokens like JWTs that contain user and client information, while handle-based tokens are opaque references. Assertion-based tokens have advantages for performance and scalability but require cryptographic protection, while handle-based tokens require validation through the authorization server. The document then examines scenarios where handle-based tokens could cause problems, such as with multiple authorization servers, and outlines secure validation steps for assertion-based tokens.
Ad
More Related Content
What's hot (20)
Similar to Why Assertion-based Access Token is preferred to Handle-based one? (20)
![[APIdays INTERFACE 2021] The Evolution of API Security for Client-side Applic...](https://cdn.slidesharecdn.com/ss_thumbnails/apidays-interface-johannstalk-210709062455-thumbnail.jpg?width=560&fit=bounds)
Ad
More from Hitachi, Ltd. OSS Solution Center. (20)
Ad
Recently uploaded (20)
Why Assertion-based Access Token is preferred to Handle-based one?
- 1. © Hitachi, Ltd. 2022. All rights reserved. Why Assertion-based Access Token is preferred to Handle-based one? APIsecure 2022 Hitachi, Ltd. Yoshiyuki Tabata Slides are available at https://www.slideshare.net/ssuserbeb7c0
- 2. 1 © Hitachi, Ltd. 2022. All rights reserved. About the speaker • Specialist in authentication and authorization Consulting for API management infrastructure and authentication/authorization systems in the financial, public, social, and industrial fields • Contributor to OSS related to authentication, authorization, and API management Keycloak (IAM OSS) 3scale (API management OSS) midPoint (IGA OSS) • Other activities Speaker at events such as Apidays, API Specifications Conference, OAuth Security Workshop, etc. Author of a Keycloak book (Japanese) and writer of web articles (Japanese) Yoshiyuki Tabata Software Engineer Hitachi, Ltd. GitHub: @y-tabata
- 3. 2 © Hitachi, Ltd. 2022. All rights reserved. Session Overview - In OAuth 2.0, there are 2 representations of an access token, Assertion-based access token and Handle-based access token. - They have their advantages and disadvantages from several viewpoints. Authorization Server Organize differences between Assertion-based access token and Handle-based one Analyze the recent trend toward Assertion-based access token is preferred Propose a solution to disadvantages of Assertion-based access token In this session, user id scope … id Assertion-based access token is a parsable token (e.g. JWT) contains information about the user and the client Handle-based access token is a reference to internal data structure does not contain any information client id internal data structure
- 4. © Hitachi, Ltd. 2022. All rights reserved. Contents 3 1. Differences between Assertion-based access token and Handle-based access token 2. A scenario where using Handle-based access token causes a problem 3. How to validate Assertion-based access token securely 4. A solution to disadvantages of Assertion-based access token
- 5. © Hitachi, Ltd. 2022. All rights reserved. Contents 4 1. Differences between Assertion-based access token and Handle-based access token 2. A scenario where using Handle-based access token causes a problem 3. How to validate Assertion-based access token securely 4. A solution to disadvantages of Assertion-based access token
- 6. 5 © Hitachi, Ltd. 2022. All rights reserved. Assertion-based access token - Assertion-based access token is a parsable token (e.g. JWT) - It contains information about the user and the client Authorization Server Access Token Resource Server Client App 1. Issue token 2. Call API 3. Validate token 4. Revoke token Point 1 The token is parsable, so if it is stolen, its contents may be leaked. Cryptographic mechanism is required to protect the contents. Point 2 The token contains information, so to validate the token, it's not mandatory to interact with the authorization server. Point 3 If the resource server doesn‘t interact with the authorization server frequently, an additional mechanism is required to notify the resource server of token revocation in the authorization server.
- 7. 6 © Hitachi, Ltd. 2022. All rights reserved. Handle-based access token - Handle-based access token is a reference to internal data structure - It does not contain any information Authorization Server Access Token Resource Server Client App 1. Issue token 2. Call API 3. Validate token 4. Revoke token Point 1 The token is “opaque”, so even if it is stolen, any information can't be leaked. Cryptographic mechanism is not required. Point 2 The token doesn't contain information, so to validate the token, it's mandatory to interact with the authorization server. Point 3 The resource server always interacts with the authorization server, so it can notice immediately the token is revoked in the authorization server.
- 8. 7 © Hitachi, Ltd. 2022. All rights reserved. Summary: Differences between Assertion and Handle - "OAuth 2.0 Threat Model and Security Considerations (RFC 6819)" also refers to these differences. Assertion-based access token Handle-based access token Description • a parsable token (e.g. JWT) • contains information about the user and the client • a reference to internal data structure • does not contain any information Validation • does not require interactions with the authorization server to validate the token • requires interactions with the authorization server to validate the token Performance /Scalability • better performance and scalability especially if the authorization server and the resource server reside on different systems • worse performance and scalability especially if the authorization server and the resource server reside on different systems Information leakage • requires cryptographic mechanisms to protect token content • does not require cryptographic mechanisms to protect token content Revocation • requires more difficult implementation • enables simple revocation Many well-known IAM products, such as Keycloak, Okta, Azure AD, AWS, Ping Identity, IdentityServer, ForgeRock AM adopt Assertion-based (JWT) access token JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (RFC 9068)" was published in October 2021 In recent years, Assertion seems to be preferred over Handle:
- 9. 8 © Hitachi, Ltd. 2022. All rights reserved. Summary: Differences between Assertion and Handle - "OAuth 2.0 Threat Model and Security Considerations (RFC 6819)" also refers to these differences. Assertion-based access token Handle-based access token Description • a parsable token (e.g. JWT) • contains information about the user and the client • a reference to internal data structure • does not contain any information Validation • does not require interactions with the authorization server to validate the token • requires interactions with the authorization server to validate the token Performance /Scalability • better performance and scalability especially if the authorization server and the resource server reside on different systems • worse performance and scalability especially if the authorization server and the resource server reside on different systems Information leakage • requires cryptographic mechanisms to protect token content • does not require cryptographic mechanisms to protect token content Revocation • requires more difficult implementation • enables simple revocation One of the biggest reasons why Assertion is preferred is for performance reasons. Recently, the number of API calls grows enormous number, the interaction overheads are not ignorable even if it is a small amount at one API call.
- 10. © Hitachi, Ltd. 2022. All rights reserved. Contents 9 1. Differences between Assertion-based access token and Handle-based access token 2. A scenario where using Handle-based access token causes a problem 3. How to validate Assertion-based access token securely 4. A solution to disadvantages of Assertion-based access token
- 11. 10 © Hitachi, Ltd. 2022. All rights reserved. Scenario: Multiple authorization servers - If client applications use access tokens issued from multiple authorization servers, Assertion-based tokens should be validated by verifying the signature using the public key of the proper authorization server. Handle-based tokens should be validated by interacting with the proper authorization server. BTW, how to identify the proper authorization server? Authorization Server A Resource Server 2. Call API 3. Validate token Authorization Server B Authorization Server C 1. Issue token Client Apps
- 12. 11 © Hitachi, Ltd. 2022. All rights reserved. Scenario: Multiple authorization servers - To identify the proper authorization server, Assertion-based tokens include the authorization server information, so we can use it. Handle-based tokens do not include any information, so we cannot use it. The proper authorization server cannot be identified if Handle-based tokens, without any extension of OAuth 2.0. There are several ways to force achieving this, but they might be unacceptable. for example, to add an additional parameter to the API request to identify the authorization server, or to interact with all authorization servers Authorization Server A Resource Server Authorization Server B Authorization Server C ?
- 13. 12 © Hitachi, Ltd. 2022. All rights reserved. Scenario: Multiple authorization servers - Actually, this scenario is quite common. Assertion-based token can easily cover this common scenario. This is one of the strong points. RS 1 Service 1 (small) Client Apps Since starting from small is best practice these days, there are a lot of services (sets of a resource server and an authorization server) in the company. Eventually, as some of those services grow well, there will be a need for users of other services to use the growth service as well. AS 1 RS 2 Service 2 (small) Client Apps AS 2 RS 1 Service 1 (big) Client Apps AS 1 RS 2 Service 2 (big) Client Apps AS 2 Instead of letting RS 2 interact with AS 1, it is possible to let client apps interact with AS 2, but that would require not a few modifications to a large number of third-party's client apps. So, that may not be a viable option.
- 14. © Hitachi, Ltd. 2022. All rights reserved. Contents 13 1. Differences between Assertion-based access token and Handle-based access token 2. A scenario where using Handle-based access token causes a problem 3. How to validate Assertion-based access token securely 4. A solution to disadvantages of Assertion-based access token
- 15. 14 © Hitachi, Ltd. 2022. All rights reserved. How to validate Assertion-based access token securely - What is the first step when validating Assertion-based token? A Check the expiration time (one of the easiest claims to validate) B Verify the signature
- 16. 15 © Hitachi, Ltd. 2022. All rights reserved. How to validate Assertion-based access token securely - What is the first step when validating Assertion-based token? A Check the expiration time (one of the easiest claims to validate) B Verify the signature Unless the signature is verified first, the possibility cannot be denied that some claims were tampered with.
- 17. 16 © Hitachi, Ltd. 2022. All rights reserved. How to validate Assertion-based access token securely - How to get the public key to verify the signature? A Request the public key to the authorization server indicated in issuer ("iss") claim B Some kind of check is required before processing A
- 18. 17 © Hitachi, Ltd. 2022. All rights reserved. How to validate Assertion-based access token securely - How to get the public key to verify the signature? A Request the public key to the authorization server indicated in issuer ("iss") claim B Some kind of check is required before processing A Again, unless the signature is verified first, the possibility cannot be denied that the “iss” claim was tampered with. An attacker could tamper with the claim, direct the resource server to a fake authorization server and convince it that an unjust access token is the correct access token, so the resource server could allow an unjust API call.
- 19. 18 © Hitachi, Ltd. 2022. All rights reserved. How to validate Assertion-based access token securely - How to get the public key to verify the signature? A Request the public key to the authorization server indicated in issuer ("iss") claim B Some kind of check is required before processing A So, some kind of check is required before processing A. For example, whitelist check, that is check whether the authz server indicated in the “iss” claim is in the whitelist or not. Even if the “iss” claim is tampered with, it can be detected when verifying the signature, because the public keys of authz servers in the whitelist cannot be tampered with.
- 20. 19 © Hitachi, Ltd. 2022. All rights reserved. Summary: Steps to validate Assertion-based access token Resource Server Authorization Server Client App Whitelist “header” : { “kid”: …, … }, “payload”: { “iss”: …, “exp”: …, “scope”: …, “aud”: …, … }, “signature”: … ① Get the authorization server ID from the “iss” claim ② Check the authorization server is in Whitelist ③ Get the public key from the authorization server by using the “kid” claim ④ Cache the public key ⑤ Verify the signature by using the public key ⑥ Check at least the following claims of the payload • “exp” claim: the expiration time • “scope” claim: the scope the client app authorized • “aud” claim: the audience, that is, the resource server that can use this token to access control Call API Response ① ③ ④ ⑤ ⑥ ②
- 21. 20 © Hitachi, Ltd. 2022. All rights reserved. Summary: Steps to validate Assertion-based access token Resource Server Authorization Server Client App Whitelist “header” : { “kid”: …, … }, “payload”: { “iss”: …, “exp”: …, “scope”: …, “aud”: …, … }, “signature”: … ① Get the authorization server ID from the “iss” claim ② Check the authorization server is in Whitelist ③ Get the public key from the authorization server by using the “kid” claim ④ Cache the public key ⑤ Verify the signature by using the public key ⑥ Check at least the following claims of the payload • “exp” claim: the expiration time • “scope” claim: the scope the client app authorized • “aud” claim: the audience, that is, the resource server that can use this token to access control Call API Response ① ③ ④ ⑤ ⑥ ②
- 22. 21 © Hitachi, Ltd. 2022. All rights reserved. Summary: Steps to validate Assertion-based access token Resource Server Authorization Server Client App Whitelist “header” : { “kid”: …, … }, “payload”: { “iss”: …, “exp”: …, “scope”: …, “aud”: …, … }, “signature”: … ① Get the authorization server ID from the “iss” claim ② Check the authorization server is in Whitelist ③ Get the public key from the authorization server by using the “kid” claim ④ Cache the public key ⑤ Verify the signature by using the public key ⑥ Check at least the following claims of the payload • “exp” claim: the expiration time • “scope” claim: the scope the client app authorized • “aud” claim: the audience, that is, the resource server that can use this token to access control Call API Response ① ③ ④ ⑤ ⑥ ②
- 23. 22 © Hitachi, Ltd. 2022. All rights reserved. Summary: Steps to validate Assertion-based access token Resource Server Authorization Server Client App Whitelist “header” : { “kid”: …, … }, “payload”: { “iss”: …, “exp”: …, “scope”: …, “aud”: …, … }, “signature”: … ① Get the authorization server ID from the “iss” claim ② Check the authorization server is in Whitelist ③ Get the public key from the authorization server by using the “kid” claim ④ Cache the public key ⑤ Verify the signature by using the public key ⑥ Check at least the following claims of the payload • “exp” claim: the expiration time • “scope” claim: the scope the client app authorized • “aud” claim: the audience, that is, the resource server that can use this token to access control Call API Response ① ③ ④ ⑤ ⑥ ②
- 24. 23 © Hitachi, Ltd. 2022. All rights reserved. Summary: Steps to validate Assertion-based access token Resource Server Authorization Server Client App Whitelist “header” : { “kid”: …, … }, “payload”: { “iss”: …, “exp”: …, “scope”: …, “aud”: …, … }, “signature”: … ① Get the authorization server ID from the “iss” claim ② Check the authorization server is in Whitelist ③ Get the public key from the authorization server by using the “kid” claim ④ Cache the public key ⑤ Verify the signature by using the public key ⑥ Check at least the following claims of the payload • “exp” claim: the expiration time • “scope” claim: the scope the client app authorized • “aud” claim: the audience, that is, the resource server that can use this token to access control Call API Response ① ③ ④ ⑤ ⑥ ②
- 25. 24 © Hitachi, Ltd. 2022. All rights reserved. Summary: Steps to validate Assertion-based access token Resource Server Authorization Server Client App Whitelist “header” : { “kid”: …, … }, “payload”: { “iss”: …, “exp”: …, “scope”: …, “aud”: …, … }, “signature”: … ① Get the authorization server ID from the “iss” claim ② Check the authorization server is in Whitelist ③ Get the public key from the authorization server by using the “kid” claim ④ Cache the public key ⑤ Verify the signature by using the public key ⑥ Check at least the following claims of the payload • “exp” claim: the expiration time • “scope” claim: the scope the client app authorized • “aud” claim: the audience, that is, the resource server that can use this token to access control Call API Response ① ③ ④ ⑤ ⑥ ②
- 26. 25 © Hitachi, Ltd. 2022. All rights reserved. Summary: Steps to validate Assertion-based access token Resource Server Authorization Server Client App Whitelist “header” : { “kid”: …, … }, “payload”: { “iss”: …, “exp”: …, “scope”: …, “aud”: …, … }, “signature”: … ① Get the authorization server ID from the “iss” claim ② Check the authorization server is in Whitelist ③ Get the public key from the authorization server by using the “kid” claim ④ Cache the public key ⑤ Verify the signature by using the public key ⑥ Check at least the following claims of the payload • “exp” claim: the expiration time • “scope” claim: the scope the client app authorized • “aud” claim: the audience, that is, the resource server that can use this token to access control Call API Response ① ③ ④ ⑤ ⑥ ②
- 27. © Hitachi, Ltd. 2022. All rights reserved. Contents 26 1. Differences between Assertion-based access token and Handle-based access token 2. A scenario where using Handle-based access token causes a problem 3. How to validate Assertion-based access token securely 4. A solution to disadvantages of Assertion-based access token
- 28. 27 © Hitachi, Ltd. 2022. All rights reserved. Disadvantages of Assertion-based access token - Recap the characteristics of both token types Regarding “Revocation”, it's a little complex, but there are options such as “OpenID Connect Back- Channel Logout”. Here, focus on “Information leakage”. To protect token content, mainly there are 2 options: Encrypt token contents Remove user privacy information Assertion-based access token Handle-based access token Description • a parsable token (e.g. JWT) • contains information about the user and the client • a reference to internal data structure • does not contain any information Validation • does not require interactions with the authorization server to validate the token • requires interactions with the authorization server to validate the token Performance /Scalability • better performance and scalability especially if the authorization server and the resource server reside on different systems • worse performance and scalability especially if the authorization server and the resource server reside on different systems Information leakage • requires cryptographic mechanisms to protect token content • does not require cryptographic mechanisms to protect token content Revocation • requires more difficult implementation • enables simple revocation
- 29. 28 © Hitachi, Ltd. 2022. All rights reserved. How to protect token content: Encrypt token contents - To encrypt token contents, we need to consider cryptographic technology and key management. Encryption might be the first thing that comes up with but is a little hard to implement like the above. Authorization Server Encrypted Access Token Resource Server Client App 1. Issue token 2. Call API 3. Validate token Encrypt Decrypt Option 1: Public Key Encryption • AS encrypts with the RS's public key. • RS decrypts with the RS's private key. • AS registers and manages a public key per RS. • AS selects the proper public key when receiving an authz request. Option 2: Common Key Encryption • AS encrypts with the common key. • RS decrypts with the same common key. • AS had better manage a common key per RS. • AS selects the proper common key when receiving an authz request. -> It's possible only AS manages the common key and AS both encrypts and decrypts, but the interaction between RS and AS is mandatory in that case.
- 30. 29 © Hitachi, Ltd. 2022. All rights reserved. How to protect token content: Remove user information - Achieve “Lightweight access token” that only includes a user identifier and does not include other user information such as private information. - This other user information is provisioned by the IDM (Identity Management) product. Authorization Server Lightweight Access Token Resource Server Client App 1. Issue token 2. Call API 3. Validate token IDM Product Only user credentials Other user information Only carries: - User identifier - Client App info (authorization info) - Other JWT info (exp, iss, ...) • While the user information linking method through access tokens at the timing of API calls is called “JIT (Just-in-Time) provisioning”, on the other hand, the provisioning method shown on the left using IDM product allows user information to be linked at arbitrary timing independently of API calls. • By using this provisioning, revocation information can also be linked, so the revocation problem of Assertion-based token might also be resolved. • cf. Keycloak is discussing Lightweight access token just now. https://github.com/keycloak/keycloak/discuss ions/9713
- 31. 30 © Hitachi, Ltd. 2022. All rights reserved. How to protect token content: Remove user information - It is also possible to use the IGA (Identity Governance and Administration) product. Rather than simply provisioning at arbitrary timing, by provisioning at appropriate timings such as ID life cycle and ID stocktaking, we can achieve ID governance for the entire system and build an integrated authentication system that adheres to proper compliances. Authorization Server (Keycloak) Lightweight Access Token Resource Server Client App 1. Issue token 2. Call API IGA Product (midPoint) Only user credentials Other user information IGA IDM ID life cycle management Entitlement management Policy management Workflow Access request management Access certification Fulfillment Auditing Identity analytics Reporting User management Group management Role management Password management The integrated authentication system by Keycloak + midPoint is one of our best solutions for the case using Assertion-based access token. IGA is an extended concept of IDM
- 32. 31 © Hitachi, Ltd. 2022. All rights reserved. Summary We organized differences between Assertion-based access token and Handle- based one. We analyzed the recent trend that Assertion-based access token is preferred and described the scenario where using Handle-based access token causes a problem. We described how to validate Assertion-based access token securely. We proposed a solution to disadvantages of Assertion-based access token, the integrated authentication system by Keycloak + midPoint. Slides are available at https://www.slideshare.net/ssuserbeb7c0
- 33. 32 © Hitachi, Ltd. 2022. All rights reserved. Trademarks • OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other countries. • GitHub is a trademark or registered trademark of GitHub, Inc. in the United States and other countries. • Other brand names and product names used in this material are trademarks, registered trademarks, or trade names of their respective holders.