APIsecure 2022

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.