Auth0 Home Blog Docs

Spring Security API and RS256 validation



We’re creating an OIDC conformant API, sending in JWT Access Tokens. We’re using the Spring Security quickstart as a starting point.

It looks like the Spring Security quickstart does some JWT token validation, but it does not validate the RS256 signature of the token via the cert. You can get the quickstart up and running without pointing it at the RS256 cert. Is there a quick way to get the quickstart to do RS256 cert validation before allowing a request into the API? I believe previous quickstarts had a way to provide the RS256 cert via properties. We’re not seeing that on the latest quickstart.

(follow-up to @jmangelo answer)

Update 1:

We seem to be getting different results than you. We are using the quickstart you referenced, and we are providing the issuer property. We see the following:

  1. No token: request is blocked as expected
  2. Valid token: request is allowed as expected
  3. Token with 1 character of the signature deleted: request is blocked as expected
  4. Token with 1 character of the signiture **CHANGED**: request is allowed - UNEXPECTED

You mention the library CAN perform a call to https://[our_account] We’re not seeing any requests for this resource using the baseline quickstart. Is there anything we need to do to make the Spring library perform this extra request? I see the node quickstart has some extra setup to configure the RS256 secret, but Spring just requires the Issuer and API Audience. Maybe the baseline quickstart won’t do the cert validation by default as it’s currently documented?

Update 2:

We used a different local proxy and with that proxy we do see requests to https://[our_account] That made us dig a little further. It looks like if you CHANGE the LAST CHARACTER of the JWT signature, then the request is allowed in. But if you change other characters it seems to not like the signature.

Could the last character be containing padding (or similar) which is deemed less critical during validation? Looks like the JWT signature is 99% validated. We were just changing a character that doesn’t matter during our validation testing?


I’m assuming that you refer to this quickstart which if correct it does indeed validate the signature of the received JWT. Technically you don’t point it directly to the certificate, but when you configure the property auth0.issuer:https://[your_account] you’re telling the issuer location is it’s also used to dynamically retrieve the necessary configuration to validate RS256 signed access tokens.

More specifically, based on the issue information, the library can automatically perform a call to https://[your_account] and use that key to validate the token signature. I did a quick test and it correctly validated the signature, for example, if you already have a valid JWT token that is able to call one of the sample API endpoints try to delete/replace the last character of the JWT token you have and send it again.

Doing the above will result in an unauthorized error given that the last part of a signed JWT is the signature and you just changed it to be different than the valid one.


My bad in suggesting to change the last character; given the signature is Base64Url encoding it may be possible (depending on the character being replaced and the one you choose) to change the last character without actually changing the output data after you have performed the Base64Url decoding. That may explain why you experienced the outcome you saw; it’s probably best to not use the single character change at the end as a method to test this due to possible inconsistencies in the result.