About
Control access or route traffic based on verified claims in a JSON web token (JWT).
About JWTs
A JSON Web Token (JWT) is an open standard for securely sharing information between a client and your apps. JWTs are commonly used to support stateless, simple, scalable, and interoperable authentication and authorization flows.
For more information, refer to the following sources:
- RFC 7519, JWT specification
- Auth0 overview about JWT
- Gloo JWT policy API docs
- Istio docs for JWT tokens and JWT claim-based routing
Common use cases
JSON Web Tokens (JWT) are commonly used to offload authentication and authorization code from your apps.
- Authentication: Instead of storing user session information server-side which can lead to scalability issues, you set up a JWT issuer, such as an OpenID Connect (OIDC) or Single Sign-on (SSO) provider. After a user authenticates, the provider returns a JWT in the response that is stored client-side. Subsequent requests from the client include the JWT, which is faster to verify than performing the entire authentication and authorization process again.
- Authorization: JWTs can have custom claims that can define a user’s scope, role, or other permissions. You can use these claims in combination with other policies to enfore fine-grained access control to your apps. By including the claim information within the JWT, the authorization process can happen faster and more scalably.
- Secure information exchange: Because the token is in JSON format, many otherwise incompatible systems and services can use the token to exchange information. The authentication and authorization features built into the token help these systems validate and trust the information.
Keep in mind that JWT data is encoded but not encrypted. As such, consider using JWT policies with no personally identifiable information (PII) or sensitive data, and only on HTTPS traffic.
JWT structure
A JWT has three parts: header, payload, and signature. These three parts are base64 encoded, combined, and separated by the dot character (.) to form the final token. To review and decode JWTs, you can use a tool such as the jwt.io debugger.
JWT parts are structured as follows:
- A header with metadata, such as the signing algorithm.
- A payload of user information or “claims” that provide identity information, such as the following common claims:
- The seven reserved claims per the RFC 7519 spec. The most common are:
iss: The entity that issued the token.sub: The subject of the token, usually a user ID.aud: The audience the token is issued for, important for security purposes so that the token is not used for other purposes.
- Additional registered claims per the OpenID Connect Core to encourage interoperability, such as
email,scope, orclient_id. For more information, see IANA JSON Web Token Claims. - Additional custom claims that you or your OIDC provider create. For an example, see the Auth0 docs.
- The seven reserved claims per the RFC 7519 spec. The most common are:
- A signature that signs the header and payload
Phase considerations for JWTs
You can apply a JWT policy before or after external authentication and authorization of a request. Where you place the JWT policy depends on many considerations that are unique to your environment, as compared in the following table. For more information about setting phases and priority, see the Phase API docs.
| Consideration | Before (Pre-AuthZ) | After (Post-AuthZ) |
|---|---|---|
| Token source | The JWT comes from a trusted source that the client already has before the request reaches the gateway. For example, the client might already be within your environment. | The JWT comes from an external authentication provider, such as OIDC or SSO. |
| Authentication | You want to filter out requests that do not already have a JWT. Or, you require external authentication only for requests with certain information that is within the JWT. | You want to require authentication for all requests. |
| Security requirements | You must validate a request’s JWT claims before external authentication, such as if your apps receive requests from many untrusted or insecure sources. | You must get a JWT from a certain OIDC provider before the request is validated. |
| Performance | You want to filter out requests as soon as possibled based on the JWT. The JWT might have all the information to make authentication decisions and comes from a trusted source. This way, you do not need to perform an additional network hop to the external authentication provider. The JWT filtering happens within the gateway proxy. | You might configure a request to authenticate with an external provider first. Aftewards, you use JWT validation to reduce the number of times that a request is sent for external authentication. |
| Filter order with other policies | The JWT information is not needed for policies that happen before it in the pre-AuthZ filter order, such as transformation or rate limiting. | The JWT information is used in complex authentication flows with policies that happen after it in the post-AuthZ filter order. For example, you might set up a complex flow to authenticate, extract, transform, and rate limit based on an appended claim to the JWT. |
Route or destination selectors
You can apply a Gloo JwtPolicy to routes or destinations. For more information about how policy selectors works, see the Apply policies concept. Keep in mind that you cannot apply multiple JWT policies to the same route or destination.
If you use both applyToRoute and applyToDestination selectors in your JWT policies, keep in mind the following behavior matrix of what routes and destinations are selected.
| Selector | Omit applyToRoutes | Select all applyToRoutes={} | Some values for applyToRoutes |
|---|---|---|---|
Omit applyDestinations |
|
|
|
Select all applyToDestinations={} |
|
|
|
Some values for applyToDestinations |
|
|
|
In the Gloo product docs, the guides are written with examples for the following:
- Apply JWT policies to destinations in the Gloo Mesh Enterprise product docs that you are currently reading.
- Apply JWT policies to routes in the Gloo Mesh Gateway product docs.
JWTs in Gloo Mesh Enterprise
With Gloo policies, you can restrict and route traffic based on information that you find in the JWT. Routing based on user identity in the JWT is more secure than unauthenticated HTTP requests from a path or header.
This JWT section contains guides for the Gloo Mesh Enterprise product. These guides have examples for applying JWT policies to destinations or to routes for east-west service mesh traffic.
If you also use Gloo Mesh Gateway to control ingress traffic, you might find the following guides helpful:
- Gloo Mesh Gateway JWT guides with examples for applying JWT policies to routes.
- JWT with external auth and transformation policies.
- More JWT examples, including clearing the route cache.
- You can use JWT policies in combination with the
gatewayDefaultDenyAllHTTPRequestsfeature gate. This way, Gloo Mesh Gateway denies requests to your HTTP routes by default.