According to documentation:
“The prefix that should be stripped before decoding the token. For example, for “Authorization: Bearer ”, prefix=“Bearer ” with a space at the end. If the header doesn’t have this exact prefix, it is considerred invalid.”
jwtheader prefix should discard invalid prefix. This is not the case when Authentication policy is applied on workload.
I think the documentation probably needs a bit update to make it more clear, here it actually treats it as if the JWT token does not exist because it could not find the given prefix in the header. This is not that different from the case which there is no JWT token at all.
Note, you should always create the authorization policy for JWT validation if you want to require the JWT token to be exist: Istio / Authentication Policy
Hello YangminZhu,
I don’t require a token to be exist, but I do require that JWTrules have exact rules with whom the http traffic gets rejected with (401) to the browser. If application in browser receives 401 it means that user should get a page to try to logon again because jwt expired. If application receives 403 (forbidden) this is another case. Either you can fix bug for RequestAuthentication policy or update the documentation so that JWT rules are clear. In this way I am having difficulties to find use of RequestAuthentication policy. Also regarding prefixes update documentation if prefixes can be given in a list or how I can define two prefixes for one issuer.
Best regards.
Dusan
Best regards.
Dusan
The RequestAuthentication alone is to tell Istio what kind of JWT token it should accept, it does not enforce that request the must include such token, even it would reject the request if the included token is has any issues (e.g. signature incorrect, expired, etc.), this behavior is chosen in the design as we want to delegate the access control to the authorization policy as the only enforcement point.
I will send out a PR to update the documentation of the JWTRules, thanks for bringing up the issue!