Hitachi, Ltd. OSS Solution Center., profile picture
Uploaded byHitachi, Ltd. OSS Solution Center.
PPTX, PDF215 views

Why Assertion-based Access Token is preferred to Handle-based one?

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.

Embed presentation

Download to read offline
© 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
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
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
© 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
© 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
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.
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.
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:
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.
© 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
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
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 ?
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.
© 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
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
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.
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
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.
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.
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 ① ③ ④ ⑤ ⑥ ②
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 ① ③ ④ ⑤ ⑥ ②
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 ① ③ ④ ⑤ ⑥ ②
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 ① ③ ④ ⑤ ⑥ ②
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 ① ③ ④ ⑤ ⑥ ②
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 ① ③ ④ ⑤ ⑥ ②
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 ① ③ ④ ⑤ ⑥ ②
© 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
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
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.
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
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
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
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.
Why Assertion-based Access Token is preferred to Handle-based one?

More Related Content

PDF
Data Lake Security on AWS
byAmazon Web Services Japan
 
PDF
202202 AWS Black Belt Online Seminar AWS Managed Rules for AWS WAF の活用
byAmazon Web Services Japan
 
PDF
AWS Black Belt Online Seminar 2018 AWS Well-Architected Framework
byAmazon Web Services Japan
 
PDF
FIDOのキホン
byYahoo!デベロッパーネットワーク
 
PDF
わたくし、やっぱりCDKを使いたいですわ〜CDK import編〜.pdf
byssuser868e2d
 
PDF
AWS Black Belt Techシリーズ Amazon Elastic Compute Cloud (Amazon EC2)
byAmazon Web Services Japan
 
PDF
20180704 AWS Black Belt Online Seminar Amazon Elastic File System (Amazon EFS...
byAmazon Web Services Japan
 
PDF
AWS EC2 Eメール制限解除 - 逆引き(rDNS)設定 申請手順
byAmazon Web Services Japan
 
Data Lake Security on AWS
byAmazon Web Services Japan
 
202202 AWS Black Belt Online Seminar AWS Managed Rules for AWS WAF の活用
byAmazon Web Services Japan
 
AWS Black Belt Online Seminar 2018 AWS Well-Architected Framework
byAmazon Web Services Japan
 
FIDOのキホン
byYahoo!デベロッパーネットワーク
 
わたくし、やっぱりCDKを使いたいですわ〜CDK import編〜.pdf
byssuser868e2d
 
AWS Black Belt Techシリーズ Amazon Elastic Compute Cloud (Amazon EC2)
byAmazon Web Services Japan
 
20180704 AWS Black Belt Online Seminar Amazon Elastic File System (Amazon EFS...
byAmazon Web Services Japan
 
AWS EC2 Eメール制限解除 - 逆引き(rDNS)設定 申請手順
byAmazon Web Services Japan
 

What's hot

PDF
AWS IoT Coreを オンプレミス環境と使う際の アーキテクチャ例 (AWS IoT Deep Dive #5)
byAmazon Web Services Japan
 
PPTX
Helidon 概要
byオラクルエンジニア通信
 
PDF
OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容＋おまけ資料
byオラクルエンジニア通信
 
PDF
AWS Black Belt Online Seminar 2017 AWS Cognito
byAmazon Web Services Japan
 
PPTX
Apache Spark on Kubernetes入門（Open Source Conference 2021 Online Hiroshima 発表資料）
byNTT DATA Technology & Innovation
 
PPTX
クラウドコストを最適化せよ！マルチクラウド時代に届けるクラウド活用2.0
byTomohisa Koyanagi
 
PDF
[Cloud OnAir] Anthosで実現するハイブリッドクラウド 〜 GKE On-Prem編 〜 2019年8月29日 放送
byGoogle Cloud Platform - Japan
 
PDF
20200219 AWS Black Belt Online Seminar オンプレミスとAWS間の冗長化接続
byAmazon Web Services Japan
 
PDF
20191029 AWS Black Belt Online Seminar Elastic Load Balancing (ELB)
byAmazon Web Services Japan
 
PDF
20190521 AWS Black Belt Online Seminar Amazon Simple Email Service (Amazon SES)
byAmazon Web Services Japan
 
PDF
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
byAmazon Web Services Japan
 
PDF
AWS Black Belt Online Seminar 2017 AWS Elastic Beanstalk
byAmazon Web Services Japan
 
PDF
NGINX Back to Basics: Ingress Controller (Japanese Webinar)
byNGINX, Inc.
 
PDF
AWS Black Belt Online Seminar 2017 AWS Storage Gateway
byAmazon Web Services Japan
 
PPTX
マイクロサービスにおける 結果整合性との戦い
byota42y
 
PDF
Kubernetesを使う上で抑えておくべきAWSの基礎概念
byShinya Mori (@mosuke5)
 
PDF
20190319 AWS Black Belt Online Seminar Amazon FSx for Lustre
byAmazon Web Services Japan
 
PDF
[D12] NonStop SQLって何? by Susumu Yamamoto
byInsight Technology, Inc.
 
PDF
自宅サーバラックの勧め BGP4編
byh-otter
 
PDF
AWS Black Belt Techシリーズ Amazon SES
byAmazon Web Services Japan
 
AWS IoT Coreを オンプレミス環境と使う際の アーキテクチャ例 (AWS IoT Deep Dive #5)
byAmazon Web Services Japan
 
Helidon 概要
byオラクルエンジニア通信
 
OCHaCafe #4 Hyperledger Fabric アプリケーション設計入門ガイドでしゃべった内容＋おまけ資料
byオラクルエンジニア通信
 
AWS Black Belt Online Seminar 2017 AWS Cognito
byAmazon Web Services Japan
 
Apache Spark on Kubernetes入門（Open Source Conference 2021 Online Hiroshima 発表資料）
byNTT DATA Technology & Innovation
 
クラウドコストを最適化せよ！マルチクラウド時代に届けるクラウド活用2.0
byTomohisa Koyanagi
 
[Cloud OnAir] Anthosで実現するハイブリッドクラウド 〜 GKE On-Prem編 〜 2019年8月29日 放送
byGoogle Cloud Platform - Japan
 
20200219 AWS Black Belt Online Seminar オンプレミスとAWS間の冗長化接続
byAmazon Web Services Japan
 
20191029 AWS Black Belt Online Seminar Elastic Load Balancing (ELB)
byAmazon Web Services Japan
 
20190521 AWS Black Belt Online Seminar Amazon Simple Email Service (Amazon SES)
byAmazon Web Services Japan
 
AWS Black Belt Online Seminar 2017 Amazon DynamoDB
byAmazon Web Services Japan
 
AWS Black Belt Online Seminar 2017 AWS Elastic Beanstalk
byAmazon Web Services Japan
 
NGINX Back to Basics: Ingress Controller (Japanese Webinar)
byNGINX, Inc.
 
AWS Black Belt Online Seminar 2017 AWS Storage Gateway
byAmazon Web Services Japan
 
マイクロサービスにおける 結果整合性との戦い
byota42y
 
Kubernetesを使う上で抑えておくべきAWSの基礎概念
byShinya Mori (@mosuke5)
 
20190319 AWS Black Belt Online Seminar Amazon FSx for Lustre
byAmazon Web Services Japan
 
[D12] NonStop SQLって何? by Susumu Yamamoto
byInsight Technology, Inc.
 
自宅サーバラックの勧め BGP4編
byh-otter
 
AWS Black Belt Techシリーズ Amazon SES
byAmazon Web Services Japan
 

Similar to Why Assertion-based Access Token is preferred to Handle-based one?

PDF
Implementing security requirements for banking API system using Open Source ...
byYuichi Nakamura
 
PPTX
Challenge to Implementing "Scalable" Authorization with Keycloak
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Implementing security and availability requirements for banking API system us...
byHitachi, Ltd. OSS Solution Center.
 
PDF
Demystifying OAuth 2.0
byKarl McGuinness
 
PDF
REST API Authentication Methods.pdf
byRubersy Ramos García
 
PDF
Implementing Authorization
byTorin Sandall
 
PDF
Distributed Authorization with Open Policy Agent.pdf
byNordic APIs
 
PPTX
How Does a Workload Authenticate an API Request?: Implementing Transaction To...
byHitachi, Ltd. OSS Solution Center.
 
PDF
CredHub and Secure Credential Management
byVMware Tanzu
 
PDF
AllTheTalks.Online 2020: "Basics of OAuth 2.0 and OpenID Connect"
byAndreas Falk
 
PDF
Learn with WSO2 - API Security
byWSO2
 
PDF
Oauth Nightmares Abstract OAuth Nightmares
byNino Ho
 
PDF
apidays Helsinki & North 2023 - API authorization with Open Policy Agent, And...
byapidays
 
PDF
JDD2015: Security in the era of modern applications and services - Bolesław D...
byPROIDEA
 
PDF
ConFoo 2015 - Securing RESTful resources with OAuth2
byRodrigo Cândido da Silva
 
PPTX
Best Practices in Building an API Security Ecosystem
byPrabath Siriwardena
 
PDF
Beyond API Authorization
byJared Hanson
 
PDF
JavaScript App Security: Auth and Identity on the Client
byJonathan LeBlanc
 
PDF
Apidays Paris 2023 - I Have an OAuth2 Access Token, Now what do I do with it,...
byapidays
 
PDF
RFC6749 et alia 20130504
byMattias Jidhage
 
Implementing security requirements for banking API system using Open Source ...
byYuichi Nakamura
 
Challenge to Implementing "Scalable" Authorization with Keycloak
byHitachi, Ltd. OSS Solution Center.
 
Implementing security and availability requirements for banking API system us...
byHitachi, Ltd. OSS Solution Center.
 
Demystifying OAuth 2.0
byKarl McGuinness
 
REST API Authentication Methods.pdf
byRubersy Ramos García
 
Implementing Authorization
byTorin Sandall
 
Distributed Authorization with Open Policy Agent.pdf
byNordic APIs
 
How Does a Workload Authenticate an API Request?: Implementing Transaction To...
byHitachi, Ltd. OSS Solution Center.
 
CredHub and Secure Credential Management
byVMware Tanzu
 
AllTheTalks.Online 2020: "Basics of OAuth 2.0 and OpenID Connect"
byAndreas Falk
 
Learn with WSO2 - API Security
byWSO2
 
Oauth Nightmares Abstract OAuth Nightmares
byNino Ho
 
apidays Helsinki & North 2023 - API authorization with Open Policy Agent, And...
byapidays
 
JDD2015: Security in the era of modern applications and services - Bolesław D...
byPROIDEA
 
ConFoo 2015 - Securing RESTful resources with OAuth2
byRodrigo Cândido da Silva
 
Best Practices in Building an API Security Ecosystem
byPrabath Siriwardena
 
Beyond API Authorization
byJared Hanson
 
JavaScript App Security: Auth and Identity on the Client
byJonathan LeBlanc
 
Apidays Paris 2023 - I Have an OAuth2 Access Token, Now what do I do with it,...
byapidays
 
RFC6749 et alia 20130504
byMattias Jidhage
 

More from Hitachi, Ltd. OSS Solution Center.

PDF
KubeConRecap_nakamura.pdf
byHitachi, Ltd. OSS Solution Center.
 
PDF
Authentication and Authorization of The Latest Keycloak
byHitachi, Ltd. OSS Solution Center.
 
PPTX
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
byHitachi, Ltd. OSS Solution Center.
 
PPTX
NGINXでの認可について考える
byHitachi, Ltd. OSS Solution Center.
 
PDF
Guide of authentication and authorization for cloud native applications with ...
byHitachi, Ltd. OSS Solution Center.
 
PDF
Secure Authorization for Agentic AI in Multi-Domain Environments
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Exploring Best Practices for Implementing Authn and Authz in a Cloud-Native E...
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Security Considerations for API Gateway Aggregation
byHitachi, Ltd. OSS Solution Center.
 
PDF
Securing AI Agent Infrastructure: AuthN/AuthZ Patterns for MCP and A2A
byHitachi, Ltd. OSS Solution Center.
 
PDF
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Mastering Authorization: Integrating Authentication and Authorization Data in...
byHitachi, Ltd. OSS Solution Center.
 
PDF
API認可を支えるKeycloakの基本と設計の考え方 ～ OAuth/OIDCによるAPI保護のベストプラクティス ～
byHitachi, Ltd. OSS Solution Center.
 
PDF
KubeCon + CloudNativeCon North America セキュリティ周りrecap
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Securing Model Context Protocol with Keycloak: AuthN/AuthZ for MCP Servers
byHitachi, Ltd. OSS Solution Center.
 
PPTX
Hitachi’s Keycloak Journey - Evolution of Business and Community
byHitachi, Ltd. OSS Solution Center.
 
PDF
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
byHitachi, Ltd. OSS Solution Center.
 
PDF
Exploring Best Practice for Implementing Authn and Authz in a Cloud-Native En...
byHitachi, Ltd. OSS Solution Center.
 
PPTX
CloudNativeSecurityCon North America 2024 Overview
byHitachi, Ltd. OSS Solution Center.
 
PDF
Let’s Join Cloud Native Computing Foundation TAG Security APAC!
byHitachi, Ltd. OSS Solution Center.
 
KubeConRecap_nakamura.pdf
byHitachi, Ltd. OSS Solution Center.
 
Authentication and Authorization of The Latest Keycloak
byHitachi, Ltd. OSS Solution Center.
 
パスキーでリードする: NGINXとKeycloakによる効率的な認証・認可
byHitachi, Ltd. OSS Solution Center.
 
NGINXでの認可について考える
byHitachi, Ltd. OSS Solution Center.
 
Guide of authentication and authorization for cloud native applications with ...
byHitachi, Ltd. OSS Solution Center.
 
Secure Authorization for Agentic AI in Multi-Domain Environments
byHitachi, Ltd. OSS Solution Center.
 
Keycloakの全体像: 基本概念、ユースケース、そして最新の開発動向
byHitachi, Ltd. OSS Solution Center.
 
Exploring Best Practices for Implementing Authn and Authz in a Cloud-Native E...
byHitachi, Ltd. OSS Solution Center.
 
Security Considerations for API Gateway Aggregation
byHitachi, Ltd. OSS Solution Center.
 
Securing AI Agent Infrastructure: AuthN/AuthZ Patterns for MCP and A2A
byHitachi, Ltd. OSS Solution Center.
 
KeycloakのCNCF incubating project入りまでのアップストリーム活動の歩み
byHitachi, Ltd. OSS Solution Center.
 
Mastering Authorization: Integrating Authentication and Authorization Data in...
byHitachi, Ltd. OSS Solution Center.
 
API認可を支えるKeycloakの基本と設計の考え方 ～ OAuth/OIDCによるAPI保護のベストプラクティス ～
byHitachi, Ltd. OSS Solution Center.
 
KubeCon + CloudNativeCon North America セキュリティ周りrecap
byHitachi, Ltd. OSS Solution Center.
 
Securing Model Context Protocol with Keycloak: AuthN/AuthZ for MCP Servers
byHitachi, Ltd. OSS Solution Center.
 
Hitachi’s Keycloak Journey - Evolution of Business and Community
byHitachi, Ltd. OSS Solution Center.
 
KubeCon NA 2023 Recap: Challenge to Implementing “Scalable” Authorization wit...
byHitachi, Ltd. OSS Solution Center.
 
Exploring Best Practice for Implementing Authn and Authz in a Cloud-Native En...
byHitachi, Ltd. OSS Solution Center.
 
CloudNativeSecurityCon North America 2024 Overview
byHitachi, Ltd. OSS Solution Center.
 
Let’s Join Cloud Native Computing Foundation TAG Security APAC!
byHitachi, Ltd. OSS Solution Center.
 

Recently uploaded

PDF
Data Virtualization in Action: Scaling APIs and Apps with FME
bySafe Software
 
PPTX
Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]
byUiPathCommunity
 
PPTX
Conversational Agents – Building Intelligent Assistants [Virtual Hands-on Wor...
byUiPathCommunity
 
PPTX
Building Agents in Microsoft Agent Framework.pptx
byUdaiappa Ramachandran
 
PDF
Day 3 - Data and Application Security - 2nd Sight Lab Cloud Security Class
by2nd Sight Lab
 
PDF
Access Control 2025: From Security Silo to Software-Defined Ecosystem
byMemoori
 
PDF
Fundamentals and Frontiers of Post Quantum Cryptography
byGokul Alex
 
PDF
How to Evaluate a High Performance Database
byScyllaDB
 
PDF
Unlocking the Power of Salesforce Architecture: Frameworks for Effective Solu...
byvarsha30tiwari
 
PDF
The State of the Gen AI economy - 2025 - The Meliora Company
byClive Dickens
 
PDF
Workshop on Sustaining & Growing Open Source Communities - GAS2025
bySammy Fung
 
PDF
10 Things AI-First Apps Do Differently by iProgrammer Solutions
byiProgrammer Solutions Private Limited
 
PDF
Real-Time Data Insight Using Microsoft Forms for Business
byElevate
 
PDF
TrustArc Webinar - Looking Ahead: The 2026 Privacy Landscape
byTrustArc
 
PPTX
communication-skills-with-technology tools
byJaleto Sunkemo
 
PPTX
MGw_MRS Benfits seu beficios de redes 4g
byJoaquimBarros18
 
PDF
AI Powered Document Processing and Data Extraction
byRobert McDermott
 
PDF
Is It Possible to Have Wi-Fi Without an Internet Provider
bySidra Jefferi
 
PPTX
Technology Consulting _ by Slidesgo.pptx
byfh82277
 
PDF
Six Shifts For 2026 (And The Next Six Years)
byDavid Armano
 
Data Virtualization in Action: Scaling APIs and Apps with FME
bySafe Software
 
Coded Agents – with UiPath SDK + LangGraph [Virtual Hands-on Workshop]
byUiPathCommunity
 
Conversational Agents – Building Intelligent Assistants [Virtual Hands-on Wor...
byUiPathCommunity
 
Building Agents in Microsoft Agent Framework.pptx
byUdaiappa Ramachandran
 
Day 3 - Data and Application Security - 2nd Sight Lab Cloud Security Class
by2nd Sight Lab
 
Access Control 2025: From Security Silo to Software-Defined Ecosystem
byMemoori
 
Fundamentals and Frontiers of Post Quantum Cryptography
byGokul Alex
 
How to Evaluate a High Performance Database
byScyllaDB
 
Unlocking the Power of Salesforce Architecture: Frameworks for Effective Solu...
byvarsha30tiwari
 
The State of the Gen AI economy - 2025 - The Meliora Company
byClive Dickens
 
Workshop on Sustaining & Growing Open Source Communities - GAS2025
bySammy Fung
 
10 Things AI-First Apps Do Differently by iProgrammer Solutions
byiProgrammer Solutions Private Limited
 
Real-Time Data Insight Using Microsoft Forms for Business
byElevate
 
TrustArc Webinar - Looking Ahead: The 2026 Privacy Landscape
byTrustArc
 
communication-skills-with-technology tools
byJaleto Sunkemo
 
MGw_MRS Benfits seu beficios de redes 4g
byJoaquimBarros18
 
AI Powered Document Processing and Data Extraction
byRobert McDermott
 
Is It Possible to Have Wi-Fi Without an Internet Provider
bySidra Jefferi
 
Technology Consulting _ by Slidesgo.pptx
byfh82277
 
Six Shifts For 2026 (And The Next Six Years)
byDavid Armano
 

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.