JWT validation pattern with `jku` and `kid` claims

[artemkovalyov]

Hi @nenaraab,

In SAP Cloud SDK, we're integrating your library to handle XSUAA authentication topics. Currently, we're fixing JWT validation that fails because of this change: tenant specific JWT signing keys

In regard to this, I have a couple of questions to ensure our implementation is secure and compliant:

• How do you ensure jku is from a whitelisted domain? Should we ensure it on Cloud SDK side?
• As I understood from the sources you consider jku trusted after ensuring that issue is trusted by checking iss?
• Does XSUAA always provide jku and kid to fetch the public key for token validation? Or it can also be only jku?
• If a mocked or testing server is used to issue JWT how can we provide a URL of this issuer to make validation work for running tests locally or other use cases requiring to override XSUAA as s token issuer?

Thank you in advance for your help! I hope this makes sense. cc @MatKuhr @newtork

Best, Artem

[nenaraab]

Hi @artemkovalyov ,

thanks for your request! You questions make perfectly sense!

• jku is only accepted for XSUAA tokens and its domain is validated as part of the https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/java-security/src/main/java/com/sap/cloud/security/token/validation/validators/XsuaaJwtIssuerValidator.java (the domain is part of the VCAP_SERVICES service binding)
• XSUAA always provides a kid but IAS doesn't. So, until IAS provides no kid we have to use the dummy kid for caching.
• In the future XSUAA might not provide jku, so the token endpoint needs to be looked up from oidc configuration endpoint.
• Please consider the following library: https://github.com/SAP/cloud-security-xsuaa-integration/tree/master/java-security-test and the following sample: https://github.com/SAP/cloud-security-xsuaa-integration/tree/master/samples/java-security-usage

Does this answer your questions? Nena

[artemkovalyov]

Thank you for the quick reply and detailed answer, @nenaraab, it clarifies a lot! Let me a bit of time to regroup with my colleagues and see if we might have any follow-up questions about potential edge cases.

[MatKuhr]

Thank you, some follow up questions from my side:

• Does the domain that is checked against include or exclude the tenant subdomain?
• From the code I deduce that the caching of token keys is not isolated on a tenant-level. Is that correct and does that mean that we don't need to worry about tenant isolation when storing & applying public keys for JWT validation?
• What is actually the oidc endpoint? I haven't encountered this term before. Does it refer to the "normal" XSUAA endpoint which is defined in VCAP services url property, so e.g. xsuaa.url.com/token_keys?

[nenaraab]

• the domain from VCAP_SERVICES does not contain the subdomain of the paas tenant
• The tenant's key-id / key-algorithm is cached per tenant specific jku: https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/java-security/src/main/java/com/sap/cloud/security/token/validation/validators/OAuth2TokenKeyServiceWithCache.java#L159
• oidc endpoint: https://xs2security.accounts400.ondemand.com/.well-known/openid-configuration. it relates to the xsuaa base url.

[MatKuhr]

Thank you so much for your help! We were pointed towards this post which indicates that reading the token keys from the jku is mandatory in a multi tenant setup. Together with the information you provided above I believe the following behaviour would be correct and are implemented by the XSUAA Java library:

1. If the jku property is present AND it points towards a resource on the XSUAA domain -> we try to fetch the token keys from there.
   1. The results are cached, isolated by tenant
   2. If there is a kid present then it is used to select the correct public key
2. Otherwise we use the oidc endpoint

As Artem said we are replacing our own implementation for JWT validation with the XSUAA Java library and need to understand possible changes in behaviour so that we can communicate that to our consumers clearly.

[nenaraab]

Hi,

Almost correct. Currently, there is a restriction to Option 1 for tokens issued by XSUAA (also because it provides the jku). See also here: https://github.com/SAP/cloud-security-xsuaa-integration/blob/master/java-security/src/main/java/com/sap/cloud/security/token/validation/validators/JwtSignatureValidator.java#L108

Best regards, Nena

[MatKuhr]

Thank you so Nena much for the detailed information, that helped us a lot.

With that we were able to integrate the XSUAA library to perform JWT validation and first consumers reported that it works, so I think we can close this issue. Thanks again for the great & fast help 👍

[nenaraab]

Okay, cool. Thanks. Happy to join for a code review if you like.

[MatKuhr]

Thanks, that would actually be great.

We currently use the library like this:

final Token token = new XsuaaToken(encodedJwt);
final OAuth2ServiceConfiguration xsuaaConfiguration = Environments.getCurrent().getXsuaaConfiguration();

if( xsuaaConfiguration == null ) {
    throw new AuthTokenAccessException("Unable to fetch XSUAA configuration from VCAP services.");
}
final CombiningValidator<Token> validator = JwtValidatorBuilder.getInstance(xsuaaConfiguration).build();

final ValidationResult result = validator.validate(token);
if( result.isValid() ) {
    return JWT.decode(encodedJwt);
}
throw new AuthTokenAccessException("The token is invalid: " + result.getErrorDescription());

In case this validation fails we fall back to our "old" implementation and try again. That way our own mocking still works and nothing can break for the consumer.

So far one of our consumers confirmed that this works. Next steps would probably be leveraging the mocking capabilites of the XSUAA lib to better test this and also to deprecate our custom implementation.

[nenaraab]

cool. Perfect and good migration idea :-)