1 of 11

Marcus Hardt (KIT)

Nicolas Liampotis (GRNET)

62nd EUGridPMA-AARC-EnCo-IGTF workshop

AARC-G081

AARC Policy: Recommendations for Token Lifetimes

23 September, 2024

1

Authentication and Authorisation for Research and Collaboration

https://aarc-community.org

2 of 11

Introduction

  • Goal: Provide recommendations for token lifetimes
  • Importance: Token lifetimes are critical as they directly impact security and usability
  • Factors influencing token lifetimes:
    • Token properties (e.g., revocation, rotation).
    • Impact of access (e.g., risk of compromise, sensitivity of resources)

2

https://docs.google.com/document/d/1U9vvJfWuE8oO7u0FcGVGr3KySvBqwjnkzKO8TKzgoX4/edit

https://aarc-community.org

3 of 11

Token Properties Overview

3

Property

Description

Advantages

Disadvantages

Bound

Token is bound to a specific instance of a relying party

Mitigate impact of compromised tokens

Delegation scenarios may lack support

Rotation

Token can only be used once → New token issued with each use

Detect compromised tokens → Trigger revocation of related tokens

- Legitimate tokens may be erroneously revoked�- Requires additional logic for token management, especially in parallel workflows

Revocable

Revoked tokens may no longer be used, regardless of initial lifetime

Longer lifetime acceptable

- Each token validation requires a network request, potentially causing delays

- Availability issues with the issuer/revocation authority can disrupt access to resources, creating a single point of failure

https://aarc-community.org

4 of 11

Token Properties Overview (Contd.)

4

Property

Description

Advantages

Disadvantages

Opaque

Token contains no information → Requires validation from the issuing authority

- No embedded information reduces the risk of data exposure

- Validations are managed by the issuer, ensuring up-to-date access permissions

- Each token validation requires a network request, potentially causing delays

- Availability issues with the issuer can disrupt access to resources, creating a single point of failure

​

Structured

Contains information about subject

Essential information readily available, e.g. lifetime

Less private

Signed

Token can be cryptographically verified by recipient

- Tokens can be validated without contacting the issuer for each request (but periodic online access is still required to obtain and refresh the signing keys)

- Protects against token tampering

​

- Cannot revoke unless revocation mechanisms are in place (e.g. CRL/OCSP for X.509 or RFC7009 for OAuth2)

https://aarc-community.org

5 of 11

Impact categories of access

See Appendix A

5

https://aarc-community.org

6 of 11

Points for discussion

  • Scope of AARC-G081: Current document covers several token types → Limit scope to specific tokens?
  • Recommendation Approach: Determine factors influencing default/min/max lifetimes
  • How to handle token lifetimes in chained token issuer scenarios

6

https://aarc-community.org

7 of 11

Points for discussion - Scope of AARC-G081

  • Scope of AARC-G081: Current document covers several token types:
    • OAuth2/OpenID Connect access tokens & refresh tokens
    • X.509 certificates
    • SSH keys & certificates
    • Kerberos tickets
    • MyTokens, VAULT Tokens
  • Q: Should AARC-G081 focus on the more commonly used token types in AARC BPA, such as OIDC/OAuth2 access and refresh tokens?

7

https://aarc-community.org

8 of 11

Scope of AARC-G081 - Recommendation Approach

Current approach to Basic Recommendations:

8

https://aarc-community.org

9 of 11

Points for discussion - Recommendation Approach

  • Recommendation Approach: Determine factors influencing default/min/max lifetimes
    • Type & properties of the token?
    • Impact category of the intended access?
    • Other mitigating controls?
      • Allowing a longer refresh token expiry with stricter rotation policies
      • Requiring a shorter access token expiry with offline validation
      • Allowing longer lifetimes for audience-restricted access tokens: Tokens restricted to a specific audience or set of resources reduce the potential damage if compromised, as they cannot be used universally
      • Combining a longer refresh token lifetime with inactivity timeouts mitigates risks from compromised or stale tokens by reducing their usable lifespan and enhancing revocation
  • Q1: Should we focus solely on token type and properties, or combine them with impact categories and mitigating controls?
  • Q2: If default, minimum, and maximum lifetimes are established, what prevents the adoption of the maximum lifetime for all tokens?

​

9

https://aarc-community.org

10 of 11

Points for discussion - Token Lifetimes in Chained Token Issuer Scenarios

  • Scenario Overview:
    • Proxy A: OAuth2 Token issuer
    • Proxy B: OAuth2 Token issuer connected as a client to Proxy A
    • Client 1: Requires minimum refresh token (RT) lifetime
    • Client 2: Requires maximum refresh token (RT) lifetime
  • Key Challenge:
    • If the refresh token (RT) issued to each client must align with the RT lifetime between Proxy A & Proxy B, how can Proxy B assign the correct lifetime to each client?
  • Q1: Should Proxy B dynamically adjust refresh token lifetimes based on the specific requirements of each client?
  • Q2: How can Proxy B ensure that the RT lifetime issued by Proxy A does not conflict with the lifetimes required by Client 1 and Client 2?
  • Q3: What mechanisms can be implemented to manage different lifetimes while maintaining consistency across the chain?

10

Proxy A

Proxy B

Client 1

Client 2

RT with MAX lifetime

RT with MIN lifetime

RT with ??? lifetime

https://aarc-community.org

11 of 11

davidg@nikhef.nl

Thank you

Any Questions?

https://aarc-community.org

© members of the AARC Community.

The work leading to these results has received funding from the European Union (GAP 101131237) and other sources

​

https://aarc-community.org