Summary
Goobi viewer can improperly authenticate OpenID Connect tokens because the token audience is not enforced as part of cryptographic verification, and a later check handles only single-string audience values. In a multi-relying-party identity provider deployment, an attacker may be authenticated as the token subject using a token intended for another application.
Goobi viewer can improperly authenticate OpenID Connect tokens because the token audience is not enforced as part of cryptographic verification, and a later check handles only single-string audience values. In a multi-relying-party identity provider deployment, an attacker may be authenticated as the token subject using a token intended for another application.
Affected context
The issue occurs in Goobi viewer deployments using the affected OpenID Connect authentication flow, particularly where one identity provider serves multiple relying parties. It is present when audience validation is performed separately from token verification and assumes that the aud claim has only one string value. The affected code path is AuthenticationEndpoint.verifyOpenIdToken.
The issue occurs in Goobi viewer deployments using the affected OpenID Connect authentication flow, particularly where one identity provider serves multiple relying parties. It is present when audience validation is performed separately from token verification and assumes that the aud claim has only one string value. The affected code path is AuthenticationEndpoint.verifyOpenIdToken.
Exploit preconditions
- Attack surface: OpenID Connect authentication endpoint exposed by the Goobi viewer web application
- Required access: Ability to obtain or present a valid token issued by the configured identity provider for another relying party
- Trigger point: Processing and validation of the OpenID Connect token during login
- Why exploitation is possible: The verifier validates the signature and issuer without enforcing the intended audience, while the subsequent audience comparison does not correctly handle all valid
audclaim representations
- Attack surface: OpenID Connect authentication endpoint exposed by the Goobi viewer web application
- Required access: Ability to obtain or present a valid token issued by the configured identity provider for another relying party
- Trigger point: Processing and validation of the OpenID Connect token during login
- Why exploitation is possible: The verifier validates the signature and issuer without enforcing the intended audience, while the subsequent audience comparison does not correctly handle all valid
audclaim representations
Why this happens
The underlying bug is a failure to bind cryptographic token validation to the intended relying party. The verifier checks the token algorithm and issuer but does not include the expected audience in the verification policy. A later single-string comparison is insufficient for the audience claim's permitted forms, allowing an otherwise valid token associated with another relying party to pass authentication checks. This behavior maps primarily to CWE-287: Improper Authentication and is also related to CWE-345: Insufficient Verification of Data Authenticity.
The underlying bug is a failure to bind cryptographic token validation to the intended relying party. The verifier checks the token algorithm and issuer but does not include the expected audience in the verification policy. A later single-string comparison is insufficient for the audience claim's permitted forms, allowing an otherwise valid token associated with another relying party to pass authentication checks. This behavior maps primarily to CWE-287: Improper Authentication and is also related to CWE-345: Insufficient Verification of Data Authenticity.
Potential impact
- An attacker may authenticate to the viewer as the token's subject
- Unauthorized access to protected digitized material or application functions could occur
- User or account impersonation may result
- Access controls based on the authenticated identity could be bypassed
- Activity may be recorded under the identity represented by the accepted token
- An attacker may authenticate to the viewer as the token's subject
- Unauthorized access to protected digitized material or application functions could occur
- User or account impersonation may result
- Access controls based on the authenticated identity could be bypassed
- Activity may be recorded under the identity represented by the accepted token
General mitigation guidance
Mitigation generally focuses on making token verification enforce the complete relying-party trust policy in one consistent validation step.
Common defensive patterns include:
- Use identity-provider or JWT libraries that validate issuer, signature, expiry, and audience claims together
- Treat
audas a claim that may have multiple values and require the configured client identifier to be an explicitly valid audience - Reject tokens intended only for other relying parties, even when their signatures and issuers are trusted
- Apply strict validation for token type, authorized party, nonce, and related OpenID Connect claims where applicable
- Keep accepted issuers, client identifiers, and signing-key policies narrowly scoped
- Limit the privileges available to identities authenticated through the viewer
- Ensure authentication failures are logged without exposing tokens or sensitive claim contents
Mitigation generally focuses on making token verification enforce the complete relying-party trust policy in one consistent validation step.
Common defensive patterns include:
- Use identity-provider or JWT libraries that validate issuer, signature, expiry, and audience claims together
- Treat
audas a claim that may have multiple values and require the configured client identifier to be an explicitly valid audience - Reject tokens intended only for other relying parties, even when their signatures and issuers are trusted
- Apply strict validation for token type, authorized party, nonce, and related OpenID Connect claims where applicable
- Keep accepted issuers, client identifiers, and signing-key policies narrowly scoped
- Limit the privileges available to identities authenticated through the viewer
- Ensure authentication failures are logged without exposing tokens or sensitive claim contents
How teams detect issues like this
Detection can combine source review, automated analysis, and runtime monitoring:
- Search for JWT verification configurations that validate issuer and signature without an expected audience
- Review code for manual
audcomparisons that assume a scalar string rather than supporting the claim's valid forms - Test authentication behavior with tokens intended for a different relying party and with multi-valued audience claims
- Use static analysis or security-focused code review rules for incomplete OpenID Connect validation
- Monitor authentication logs for rejected or accepted tokens whose audience does not match the configured client identity
- Enforce CI policies requiring standardized, centrally reviewed token-validation components
Detection can combine source review, automated analysis, and runtime monitoring:
- Search for JWT verification configurations that validate issuer and signature without an expected audience
- Review code for manual
audcomparisons that assume a scalar string rather than supporting the claim's valid forms - Test authentication behavior with tokens intended for a different relying party and with multi-valued audience claims
- Use static analysis or security-focused code review rules for incomplete OpenID Connect validation
- Monitor authentication logs for rejected or accepted tokens whose audience does not match the configured client identity
- Enforce CI policies requiring standardized, centrally reviewed token-validation components
