Hi,
I am a newby and I am not affiliated with the Istio project…
I don’t really understand why “it’s deprecated to store Access Token on the client side” and how you can store it elsewhere?
> Unless you’re talking about storing the token of a hosted service outside the BFF cluster. User A → Browser → token A → BFF → Token B → External service B. (if yes look at the end)
According to: JSON Web Token - Wikipedia
The backend generates a token using the client credentials, and the client uses the token to access the backend resources, so the token must be stored on the client…
If that helps, here’s how I do it with Istio:
- I have an “authenticator” in my backend that uses Jose to generate a token after verifying the client’s credentials (using a secure connection: HTTPS). But you can use an external authenticator like Google or any social network ones.
- The client stores the token on the client browser’s memory, and the browser’s isolation ensures that no other tab can access it.
- When the client calls the back-end service, it injects this token on the request header.
Example: Authorization: Bearer «place the token here».
- The istio ingress is configured to verify the token; the documentation is here: Istio / JWT Token
a) Replace the “issuer” value with your own or Google’s one.
b) Replace the JWKS (only public part) with your own (or Google’s one. You can also store it as a secret).
c) If you use your own authenticator, make sure that the subject (sub) is the same in the key and the token…
If you have any problems, go to https://jwt.io and use the webui to verify the token and keys.
If you want to customize the header, look below at “fromHeaders”.
If you want to retrieve a decoded version of the token payload in your service, see “outputPayloadToHeader” and “forwardOriginalToken” below, it may be useful to retrieve the user type for example.
apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
name: authenticator-jwks
namespace: istio-system
spec:
selector:
matchLabels:
istio: ingressgateway
jwtRules:
- issuer: "auth@myapp.io"
jwks: |
{ "keys": [{"kty":"RSA","n":"lkp5....gHpCQ","e":"AQAB","kid":"4d58...ea6","alg":"RS256"}]}
fromHeaders:
- name: Authorization
prefix: "Bearer "
outputPayloadToHeader: x-jwt
forwardOriginalToken: true
To improve the internal cluster security (man in the middle), do not forget to enable STRICT mTLS, but do this step by step this part can be tricky…
For the external service case, I do not know of any mechanism in Istio to do so and I do not think it is the role of the ingress nor the egress (the token and API key are often user-specific) but rather that of the BFF; because in this case it is the BFF the client of the service. I don’t know what framework you’re using for the BFF, but I guess there must be a notion of user session. When the user logs in, I would retrieve the token or API key from a database and add it to the user session data (memory or cache/redis). Like this when from a request to the outside the BFF will find it easily…
You may lock at: Citadel is also one of the main components in Istio service mesh. It provides strong service-to-service and end-user authentication with built-in identity and credential management. This can be used to upgrade unencrypted traffic in the service mesh. Using Citadel, operators can enforce policies based on service identity rather than on network controls.
