Library forces you to validate audience/aud claim

[ianling]

When using the JwtVerifier struct to validate ID tokens and Access tokens, you are forced to provide a value for the aud claim. I don't want to validate the aud claim and there is no way to turn this off.

[monde]

@ianling the audience value coming back from Okta is known (the Okta Auth server's URI), why wouldn't you validate it?

https://developer.okta.com/blog/2020/12/21/beginners-guide-to-jwt

Audience (aud) - A list of parties the token should be sent to and parsed by. In the access token, the audience is the Okta Authorization Server’s Issuer URI requesting Okta API access or the customer’s API URI requesting customer API access. In the id token, however, it’s the client ID. Working with Okta, only one server is being targeted, so the list should only contain one item.

https://developer.okta.com/docs/reference/api/oidc/

aud is required and must be the same value as the Authorization Server issuer that mints the ID or access token. This value is published in the metadata for your Authorization Server.

https://developer.okta.com/docs/guides/build-self-signed-jwt/java/main/#gather-claims-information

[ianling]

@monde we have multiple applications (client IDs/auds) configured in Okta and we are trying to seamlessly integrate authentication across these applications.

For example, we want a user to be able to authenticate in AppFoo and be able to seamlessly pass their ID/Access tokens to AppBar and AppBaz without needing to initiate the entire SSO flow again. (We are in the process of unifying our SSO sign-in process and this is just the first stage)

We don't want AppFoo, AppBar, and AppBaz to need to keep track of each other's Okta client IDs so that we can validate the aud claim, as this doesn't provide any additional security in our situation (we fully control all of the applications in our Okta setup, so we don't really care what the aud claim contains -- any aud is fine). All of these applications are owned by different teams, and it would be a huge hassle if one team needed to change their Okta client ID in all of the other applications.