JWT Authentication in the Apollo Router

The Apollo Router supports request authentication and key rotation via the JSON Web Token (JWT) and JSON Web Key (JWK) standards. This support is compatible with popular identity providers (IdPs) like Okta and Auth0.

By enabling JWT authentication, you can block malicious traffic at the edge of your graph instead of relying on header forwarding to propagate tokens to your subgraphs.

To use this feature:

• You must have an identity provider (IdP) or similar service that issues JWTs to authenticated clients using one of the signature algorithms supported by the jsonwebtoken Rust library (most popular signing algorithms are supported).
• You must have a GraphOS Enterprise plan and connect your router to GraphOS.

If you issue JWTs via a popular third-party IdP (Auth0, Okta, PingOne, etc.), adding JWT authentication to your router is comparatively straightforward. If you use your own custom IdP, advanced configuration is required.

How it works

These are the high-level steps of JWT-based authentication with the Apollo Router:

1. Whenever a client authenticates with your system, your IdP issues that client a valid JSON Web Token (JWT).

2. In its subsequent requests to your router, the authenticated client provides its JWT in a designated HTTP header.

3. Whenever your router receives a client request, it extracts the JWT from the designated header (if present).

   • If no JWT is present, the request proceeds. You can reject requests with no accompanying JWT at a later phase (see below).

4. Your router validates the extracted JWT using a corresponding JSON Web Key (JWK).

   • Your router obtains all of its known JWKs from URLs that you specify in its configuration file. Each URL provides its keys within a single JSON object called a JWK Set (or a JWKS).
   • If validation fails, the router rejects the request. This can occur if the JWT is malformed, or if it's been expired for more than 60 seconds (this window accounts for synchronization issues).

5. The router extracts all claims from the validated JWT and includes them in the request's context, making them available to your router customizations, such as Rhai scripts.

6. Your customizations can handle the request differently depending on the details of the extracted claims, and/or you can propagate the claims to subgraphs to enable more granular access control.

   • For examples, see below.

Turning it on

You enable JWT authentication for your router with the following steps:

1. Set configuration options for JWT authentication in your router's YAML config file, under the authentication key:

   YAML

   router.yaml

   1
   authentication:
   2
    jwt:
   3
      jwks: # This key is required.
   4
        - url: https://dev-zzp5enui.us.auth0.com/.well-known/jwks.json
   5
          issuer: <optional name of issuer>
   6
   
   7
      # These keys are optional. Default values are shown.
   8
      header_name: Authorization
   9
      header_value_prefix: Bearer

   Copy

   These options are documented below.

2. Pass all of the following to the router executable on startup:

   • The path to the router's YAML configuration file (via the --config option)
   • The graph ref for the GraphOS variant your router should use (via the APOLLO_GRAPH_REF environment variable)
   • A graph API key that enables the router to authenticate with GraphOS to fetch its supergraph schema (via the APOLLO_KEY environment variable)
   Bash

   1
   APOLLO_GRAPH_REF=docs-example-graph@main APOLLO_KEY="..." ./router --config router.yaml

   Copy

When the router starts up, it displays a log message that confirms which jwks are in use:

1
2023-02-03T14:05:28.018932Z  INFO JWT authentication using JWKSets from jwks=[{ url: "file:///router/jwks.json" }]

Configuration options

The following configuration options are supported:

Working with JWT claims

After the Apollo Router validates a client request's JWT, it adds that token's claims to the request's context at this key: apollo_authentication::JWT::claims

Claims are the individual details of a JWT's scope. They might include details like the ID of the associated user, any roles assigned to that user, and the JWT's expiration time. See the spec.

Because claims are added to the context, you can define custom logic for handling each request based on the details of its claims. You can define this logic within a Rhai script or external coprocessor at the supergraph service level (for more on these options, see Customizations for the Apollo Router).

Below are three example Rhai script customizations that demonstrate actions the router can perform based on a request's claims.

Example: Rejecting unauthenticated requests

Below is an example Rhai script that rejects requests that don't present a valid JWT.

1
fn supergraph_service(service) {
2
    const request_callback = Fn("process_request");
3
    service.map_request(request_callback);
4
}
5

6
// This will examine our context to determine if our user is authenticated.
7
fn process_request(request) {
8
    // Router.APOLLO_AUTHENTICATION_JWT_CLAIMS is a Rhai-scope
9
    // constant with value `apollo_authentication::JWT::claims`
10
    let claims = request.context[Router.APOLLO_AUTHENTICATION_JWT_CLAIMS];
11
    if claims == () {
12
        throw #{
13
            status: 401,
14
            body: #{
15
                errors: [#{
16
                    message: "The request is not authenticated",
17
                    extensions: #{
18
                        code: "AUTH_ERROR"
19
                    }
20
                }]
21
            }
22
        };
23
    }
24
    // We are happy we are authenticated.
25
}

Example: Forwarding claims to subgraphs

Below is an example Rhai script that forwards a JWT's claims to individual subgraphs via HTTP headers (one header for each claim). This enables each subgraph to define logic to handle (or potentially reject) incoming requests based on claim details.

1
fn subgraph_service(service, subgraph) {
2
  let f = |request| {
3
    // Router.APOLLO_AUTHENTICATION_JWT_CLAIMS is a Rhai-scope
4
    // constant with value `apollo_authentication::JWT::claims`
5
    let claims = request.context[Router.APOLLO_AUTHENTICATION_JWT_CLAIMS];
6
    if claims ==() {
7
      throw #{
8
        status: 401
9
      };
10
    }
11
    // Add each claim key-value pair as a separate HTTP header
12
    for key in claims.keys() {
13
      request.subgraph.headers[key] = claims[key];
14
    }
15
  };
16

17
  service.map_request(f);
18
}

Example: Throwing errors for invalid claims

Below is an example Rhai script that throws distinct errors for different invalid JWT claim details.

1
fn supergraph_service(service) {
2
    // Rhai mechanism for creating a function pointer
3
    const request_callback = Fn("process_request");
4
    service.map_request(request_callback); // Register the callback
5
}
6

7
fn process_request(request) {
8
    try {
9
        // Router.APOLLO_AUTHENTICATION_JWT_CLAIMS is a Rhai-scope
10
        // constant with value `apollo_authentication::JWT::claims`
11
        let claims = request.context[Router.APOLLO_AUTHENTICATION_JWT_CLAIMS];
12
        if claims == () {
13
            throw #{
14
                status: 401,
15
                body: #{
16
                    errors: [#{
17
                        message: "No claims presented in this request"
18
                    }]
19
                }
20
            };
21
        }
22
        if !claims.contains("iss") {
23
            throw #{
24
                status: 401,
25
                message: "No issuer presented in this request"
26
            };
27
        }
28
        if claims["iss"] != "https://idp.local" {
29
            throw #{
30
                status: 401,
31
                body: #{
32
                    errors: [#{
33
                        message: `Issuer ${claims.iss} is not accepted here`
34
                    }]
35
                }
36
            };
37
        }
38
        // Happy path: We have valid claims from the correct idP.
39
        // Proceed accordingly (in this case, we just log the claims).
40
        print(`claims: ${claims}`);
41
    }
42
    catch(err)
43
    {
44
        // log any errors
45
        log_error(`Error during claims processing: ${err}`);
46
        throw err;
47
    }
48
}

Creating your own JWKS (advanced)

The Apollo Router obtains each JSON Web Key (JWK) that it uses from the URLs that you specify via the jwks configuration option. Each URL must provide a set of valid JWKs in a single JSON object called a JWK Set (or JWKS).

To provide a JWKS to your router, configure your IdP service to do the following whenever its collection of valid JWKs changes (such as when a JWK expires or is rotated):

1. Generate a valid JWKS object that includes the details of every JWK that the router requires to perform token validation.
2. Write the JWKS object to a location that your router can reach via a file:// or https:// URL.
   • ⚠️ If any of your JWKs uses a symmetric signature algorithm (such as HS256), always use a file:// URL. Symmetric signature algorithms use a shared key that should never be accessible over the network.

Again, make sure the IdP is configured to perform these steps every time its collection of JWKs changes!

JWKS format

A JWKS is a JSON object with a single top-level property: keys. The value of keys is an array of objects that each represent a single JWK:

1
{
2
  "keys": [
3
    {
4
      // These JWK properties are explained below.
5
      "kty": "RSA",
6
      "alg": "RS256",
7
      "kid": "abc123",
8
      "use": "sig",
9
      "n": "0vx7agoebGcQSuu...",
10
      "e": "AQAB"
11
    }
12
  ]
13
}

It's common for the keys array to contain only a single JWK, or sometimes two if your IdP is in the process of rotating a key.

JWK object reference

JWK object properties fall into two categories:

• Universal properties. You include these in your JWK objects regardless of which signature algorithm you use.
• Algorithm-specific properties. You include these only for JWK objects that use a corresponding signature algorithm.

Universal properties

These properties apply to any JWK:

Algorithm-specific properties

RSA

1
{
2
  // Universal properties
3
  "kty": "RSA",
4
  "alg": "RS256",
5
  "kid": "abc123",
6

7
  // Algorithm-specific properties
8
  "n": "0vx7agoebGcQSuu...", // Shortened for readability
9
  "e": "AQAB"
10
}

EC (elliptic curve)

1
{
2
  // Universal properties
3
  "kty": "EC",
4
  "alg": "ES256",
5
  "kid": "afda85e09a320cf748177874592de64d",
6
  "use": "sig",
7

8
  // Algorithm-specific properties
9
  "crv": "P-256",
10
  "x": "opFUViwCYVZLmsbG2cJTA9uPvOF5Gg8W7uNhrcorGhI",
11
  "y": "bPxvCFKmlqTdEFc34OekvpviUUyelGrbi020dlgIsqo"
12
}

Symmetric key algorithms (such as HMAC)

1
{
2
  // Universal properties
3
  "kty": "oct",
4
  "alg": "HS256",
5
  "kid": "key1",
6
  "use": "sig",
7

8
  // Symmetric-algorithm-specific property
9
  "k": "c2VjcmV0Cg==" // ⚠️ This is a base64-encoded shared secret! ⚠️
10
}

JWK matching

To match an incoming JWT with its corresponding JWK, the router proceeds through descending "specificity levels" of match criteria until it identifies the first compatible JWK from its JWK Sets:

1. The JWT and JWK match both kid and alg exactly.
2. The JWT and JWK match kid, and the JWT's alg is compatible with the JWK's kty.
3. The JWT and JWK match alg exactly.
4. The JWT's alg is compatible with the JWK's kty.

This matching strategy is necessary because some identity providers (IdPs) don't specify alg or kid values in their JWKS. However, they always specify a kty, because that value is required by the JWK specification.

Forwarding JWTs to subgraphs

Because the Apollo Router handles validating incoming JWTs, you rarely need to pass those JWTs to individual subgraphs in their entirety. Instead, you usually want to pass JWT claims to subgraphs to enable fine-grained access control.

If you do need to pass entire JWTs to subgraphs, you can do so via the Apollo Router's general-purpose HTTP header propagation settings.

Observability

If your router enables tracing, the JWT authentication plugin has its own tracing span: authentication_plugin

If your router enables metrics collection via Prometheus, the JWT authentication plugin provides and exports the following metrics:

• apollo_authentication_failure_count
• apollo_authentication_success_count

Those metrics have the following shapes:

1
# HELP apollo_authentication_failure_count apollo_authentication_failure_count
2
# TYPE apollo_authentication_failure_count counter
3
apollo_authentication_failure_count{kind="JWT",service_name="apollo-router"} 1
4

5
# HELP apollo_authentication_success_count apollo_authentication_success_count
6
# TYPE apollo_authentication_success_count counter
7
apollo_authentication_success_count{kind="JWT",service_name="apollo-router"} 11