0

I have a static react app which users login via an Okta SPA app.

The app receives a JWT, which it is stored in the browser, and passed to the backend API via Authentication header on every request.

The API using Azure API Management. They provide "policies" to validate JWT tokens.

<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="JWT Token invalid" require-scheme="Bearer">
    <openid-config url="https://dev-999999.okta.com/oauth2/default/.well-known/oauth-authorization-server" />
    <audiences>
        <audience>api://default</audience>
    </audiences>
    <issuers>
        <issuer>https://dev-999999.okta.com/oauth2/default</issuer>
    </issuers>
</validate-jwt>

I assume that the "validation" is using a public key (obtained by the OpenId configuration url?) to check that the JWT was signed by my okta app? And that it wouldn't be possible to spoof a JWT in a way that would pass this validation?

If that's the case, is it secure to just rely on this validation alone, or are additional request needed to okta? I was hoping to use additional "group" claims on the token to manage RBAC.

I think I understand how this works (more or less), but I just wanted to make sure I'm not overlooking something.

NSjonas
  • 143
  • 5

1 Answers1

1

Given enough time and money, anything can be spoofed. The real risk is the disclosure of the private key allowing forged data to be signed.

Signed JWTs use RSA private keys to sign the data (JWT header and payload) and public keys to verify the signature.

Validating a JWT means that the signature is valid and was signed by the correct authority (private key). Some validations process additional claims.

Validation does not mean that the contents (claims) are valid for your use case. You should check expiration (exp), issuer (iss), audience (aud), email, etc depending on which claims you depend on for authorization.

The Azure Policy statement can do some/all of those validation checks for you.

John Hanley
  • 320
  • 1
  • 6
  • `Validation does not mean that the contents (claims) are valid for your use case`, EG: actually checking that the token is not expired, or that the user "group" has permission to make the given request? I assume I can trust the "contents" of the claims themselves to be accurate tho, right? – NSjonas Sep 17 '21 at 02:24
  • 1
    @NSjonas Yes, the signature provides trust that the contents have not been modified. In my answer, I meant that you should verify the claims are correct for their intended use. For example, a token might be created for one service (compute) and then incorrectly used for a different service (storage). – John Hanley Sep 17 '21 at 03:32