Usespring-addons-starter-oidc to integrate Cognito, but also allow a custom, non-OIDC JWT access?

[bdruth]

Hi, is it possible to use this library in conjunction with a requirement/need to accept a custom, hand-crafted (long-lived) JWT for another system to hit a particular endpoint on the service? In general, we've configured the add-on as a resource-server w/ OIDC integrated with Cognito and that's working great (thank you!!) - but we also need another service to access a particular endpoint with a custom JWT that's generated outside of any OIDC context/issuer.

Can that be made to work?

Cheers,
Brice

[ch4mpy]

Yes, it is possible, but I'd advise you don't do that. You should probably be using client_credentials flow and have tokens delivered by your OpenID Provider (Cognito) to the programatic client.

If you really want to stick with your idea:

• If the public key to validate this token can be downloaded from somewhere, then it is just "static" multi-tenancy which is natively implemented by spring-addons: just add an entry in com.c4-soft.springaddons.oidc.ops with iss or jwk-set-uri pointing to the public key for token validation.
• If the token validation is custom too, then it requires the same as without spring-addons: you provide with a dedicated SecurityFilterChain for the additional authorization mechanism (your "hand-crafted" JWTs). This filter-chain should have a smart enough securityMatcher to intercept only requests for this new authorization mechanism (based on the path to your particular endpoint, a header, origin, or whatever you have at hand). This filter-chain should also have an order between @Order(Ordered.HIGHEST_PRECEDENCE) and @Order(Ordered.LOWEST_PRECEDENCE - 2).

[bdruth]

You should probably be using client_credentials flow and have tokens delivered by your OpenID Provider (Cognito) to the programatic client

If I understand you right, what you're saying is "the service that's wanting to use a non-cognito token and just get by with a custom, long-lived token, should really implement the client_credentials flow with cognito so we don't have to do anything special on the resource-server side" - right? I agree ... unfortunately, I'm not sure what options we have in that space - the "other service" is a legacy system that might be option constrained.

If I understand the first option - if the JWK is made available at a url, we can just define a new entry and use jwk-set-uri and basically be done? That would be ideal.

[ch4mpy]

Cognito only solution

Long-lived access tokens are a security risk. As client_credentials client side is rather easy to implement, including in most "legacy" systems, it is worth trying to use only Cognito (and short lived access-tokens).

Multi-issuers solution

A JWT validation involves checking the payload integrity using the authorization server public key. Spring Security need the JWK-set to configure the JWT decoders (in charge of JWTs decoding and validation). Decoders are configured with the JWK-set (and not the public key directly) because the authorization server can (and should) rotate signing keys.

If you can provide this URI, then you have nothing more to do and tokens will be accepted if issued by Cognito or by your other authorization server issuing the "long-lived" tokens for the legacy system.

If your tokens are not issued by an authorization server or if the server issuing this tokens doesn't expose its JWK set, then this JWT might not be part of an OAuth2 flow and you can't use Spring Security for resource servers with JWTs. In that case, spring-addons-starter-oidc can help to configure the filter-chain for Cognito, but you'll have to write the Java configuration for another very custom SecurityFilterChain with:

• an order between @Order(Ordered.HIGHEST_PRECEDENCE) and @Order(Ordered.LOWEST_PRECEDENCE - 2)
• a securityMatcher smart enough for this SecurityFilterChain to apply only to requests from your legacy system (based on path, a header, source IP, or whatever request attribute)
• something to validate the token with your own custom logic (maybe an authentication manager checking if the token string is included in a few trusted values in configuration as if it was just an ordinary secret)

[bdruth]

Awesome, thank you! Appreciate the detailed response.