Description
Before reporting an issue
- I have read and understood the above terms for submitting issues, and I understand that my issue may be closed without action if I do not follow them.
Area
core
Describe the bug
In several parts of the codebase, UUID.randomUUID() is used to generate values like authorization codes and token identifiers. While this produces 128-bit UUIDs, only ~122 bits are truly random, as 6 bits are fixed by the UUID specification (version and variant fields).
Security standards such as ANSSI R18 and NIST SP 800-90A/57 require at least 128 bits of entropy for secrets, tokens, and other security-sensitive identifiers. This means the current use of UUID.randomUUID() falls short of compliance and introduces a theoretical reduction in security strength.
Version
26.1.4
Regression
- The issue is a regression
Expected behavior
Access token identifiers should be generated with at least 128 bits of entropy, aligning with general cryptographic best practices and recommendations.
Actual behavior
Access token IDs are generated using java.util.UUID.randomUUID(), resulting in Type 4 UUIDs. These UUIDs have constraints that limit their maximum entropy to 122 bits.
How to Reproduce?
- Generate an access token within Keycloak.
- Inspect the generation logic, specifically the KeycloakModelUtils.generateId() method, confirming its reliance on UUID.randomUUID().
- Analyze the properties of the generated token ID (e.g., the jti claim if it's a JWT).
- Confirm the ID is a Type 4 UUID and thus limited to a theoretical maximum of 122 bits of entropy due to the fixed bits in its format.
Anything else?
Entropy Requirements Comparison – NIST vs ANSSI
| Use Case | Recommended Entropy | NIST Guidance | ANSSI Guidance (R18, R24, etc.) | UUID.randomUUID() Status |
|---|---|---|---|---|
| Authorization Codes | ≥ 128 bits | SP 800-63B §5.1.4.2: At least 128 bits for high assurance | [R18] Requires random generation with ≥ 128 bits of entropy | Only ~122 bits |
| Access Tokens / Bearer Tokens | ≥ 128 bits | SP 800-133 Rev. 2: Secure key generation requires full entropy | [R24] Requires access tokens to be randomly generated with ≥ 128 bits of entropy | Only ~122 bits |
| Client Secrets / Shared Keys | ≥ 128 bits | SP 800-57 Part 1 Rev. 5: Symmetric keys must have at least 128-bit strength | [R35] Must be generated by CSPRNG with ≥ 128-bit entropy | Often falls short |
| Nonce / Anti-Replay Values | ≥ 128 bits | SP 800-90A Rev.1: Nonces should be random or unique enough to avoid reuse | [R14, R15] Requires CSPRNG and ≥ 128-bit entropy | ~122 bits |
| Session Identifiers / Correlation IDs | ≥ 112 bits | [SP 800-63B]: At least 112 bits of entropy for session IDs | Not explicitly covered, but same 128-bit rule often applies | Borderline |
| Random Identifiers (non-security sensitive) | ≥ 64–80 bits (low risk) | Acceptable for non-sensitive use cases | Acceptable if not used for authentication/authorization | Acceptable |
Proposal
Based on the assessment from the team on the findings below, to evaluate the impact, I’d like us to replace UUID.randomUUID() by SecureRandom to produce full 128-bit entropy values. Please review the findings and comment on whether or not the idea makes sense.
Findings
-
- Issue: UUID.randomUUID() provides ~122 bits of entropy and may not meet security standards.
-
core/src/main/java/org/keycloak/AbstractOAuthClient.java#L46
- Issue: UUID.randomUUID() provides ~122 bits of entropy and may not meet security standards.
-
core/src/main/java/org/keycloak/TokenIdGenerator.java#L31
- Issue: UUID.randomUUID() provides ~122 bits of entropy and may not meet security standards.
-
- Issue: UUID.randomUUID() provides ~122 bits of entropy and may not meet security standards.
-
- Issue: UUID.randomUUID() provides ~122 bits of entropy and may not meet security standards.
-
integration/client-cli/admin-cli/src/main/java/org/keycloak/client/cli/util/AuthUtil.java#L200
- Issue: UUID.randomUUID() provides ~122 bits of entropy and may not meet security standards.
-
- Issue: UUID.randomUUID() provides ~122 bits of entropy and may not meet security standards.