Authorization directives can be used in your schema to define granular authorization rules on the field definition level. Documentation can be found at @authenticated and @requiresScopes.
Cosmo router supports authenticating incoming requests using JWKS authentication. The JSON Web Key Set (JWKS) is a set of keys that contains the public keys used to verify any JSON Web Token (JWT) issued by the authorization server and signed using a signing algorithm. To enable an authentication provider, add it to your configuration

​
Current Configuration

In the current router version, the configuration and behavior of authentication have been redesigned. Instead of specifying a configuration per JWKS endpoint, you can now list multiple endpoints where all header rules apply to. Each JWKS endpoint can optionally specify a whitelist of supported JWT algorithms.

​
Configuration

authentication:
  jwt:
    jwks:
      - url: https://example.com/.well-known/jwks.json
        refresh_interval: 1m
        algorithms: ["RS256"]
      - url: https://example2.com/.well-known/jwks.json
        refresh_interval: 2m
        # optional list of allowed algorithms per JWKS
        algorithms: ["RS256", "EdDSA", "HS512"]
        audiences:
          - http://aud1
          - http://aud2
      - symmetric_algorithm: HS256
        secret: <your_secret>
        header_key_id: some-key-id
    header_name: Authorization # Optional, Authorization is the default value
    header_value_prefix: Bearer # Optional, Bearer is the default value
    header_sources:
      - type: header
        name: X-Auth-Token
        value_prefixes: [Token, MyToken]
      - type: header
        name: X-Authorization
The router configuration facilitates the setup of multiple JWKS (JSON Web Key Set) endpoints, each customizable with distinct retrieval settings. It allows specification of supported JWT (JSON Web Token) algorithms per endpoint. It also allows the use of secrets for symmetric algorithms, as it would be a security risk to expose them over a JWKS endpoint. Centralizing header rules application across all keys from every JWKS endpoint simplifies management. This setup grants centralized control while offering flexibility in the retrieval and processing of keys. For more information on the attributes, visit the auth configuration parameter section page here.

​
Old Router configuration (< 0.168.1)

authentication:
  providers:
    - name: My Auth Provider # Optional, used for error messages and diagnostics
      jwks: # JWKS provider configuration
        url: https://example.com/.well-known/jwks.json # URL to load the JWKS from (Authorization server)
        header_names: [Authorization] # Optional, Authorization is the default value
        header_value_prefixes: [Bearer] # Optional, Bearer is the default value
        refresh_interval: 1m # Optional, How often the JWK is refreshed
Using multiple authentication providers is also supported. If authentication with any of the providers succeeds, the claims from the token are decoded and made available through the request pipeline. Notice that providers are tried in the same order as they are defined in the configuration and once a provider authenticates a request, no other providers are tried.

​
Enforce authentication

By default, requests without authentication information are allowed. Only requests with invalid authentication information (e.g. an incorrectly signed token) produce a 403 Forbidden response. To disable anonymous requests, use the Authorization configuration: 
authorization:
  require_authentication: true
This causes requests without authorization information to produce a 401 Unauthorized Authentication information is also available to custom modules. See Access Authenticated Information.

​
Forwarding authentication headers

By default, the router won’t forward authentication headers to subgraphs, but if desired this can be configured using Proxy capabilities.