> ## Documentation Index
> Fetch the complete documentation index at: https://docs.withsutro.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication overview

> Understand how Sutro authenticates Members and Builders using JWTs and mTLS, and learn how API requests are validated

## Users

Sutro can be accessed by two main types of users:

1. **[Members](/docs/getting-started/auth/members)**: Users within your organization who can access the Sutro Console. They can review usage, manage Builders, and configure certificates for verifying Builder requests.
2. **[Builders](/docs/getting-started/auth/builders)**: End users or clients who build and run apps that integrate with Sutro.

## Certificates

Our security model relies on two complementary mechanisms:

1. [Mutual TLS (mTLS)](/docs/getting-started/auth/mutual-tls) ensures that only trusted servers can call our APIs.
2. [JSON Web Tokens (JWTs)](/docs/getting-started/auth/jwts) ensure that only authorized Builders can access the resources they are allowed to use.

Sutro relies on **mTLS** for all server-to-server communication and **JWTs** for all user-level access control. This separation provides strong, flexible, and auditable security.

## What happens during validation

During request processing we confirm the JWT is well-formed, that it targets the Sutro API, and that (for Builder traffic) the request arrives over mutual TLS. When all validation points pass, we continue execution; otherwise the request is rejected.

<Steps>
  <Step title="Inspect the JWT structure">
    * The request must include a JWT that is well-formed.
    * Malformed or missing tokens are rejected before any additional checks run.
  </Step>

  <Step title="Validate standard claims">
    * The `aud` claim must equal `"https://sapi.withsutro.com"`.
    * The `iss` claim must map to an issuer that the organization has previously registered with Sutro.
  </Step>

  <Step title="Verify the signature">
    * Sutro looks up the public certificate associated with the issuer.
    * The JWT's signature must verify against that certificate; if it fails, the request is denied.
  </Step>

  <Step title="Check the subject (SID)">
    * The `sub` claim must resolve to a known Member or Builder.
    * That principal must belong to the customer sending the request.
  </Step>

  <Step title="Enforce Builder mTLS">
    * If the SID represents a Builder, the request must arrive over mTLS.
    * The presented client certificate must match the Builder's certificate stored with Sutro.
  </Step>
</Steps>

<Check>
  When all stages succeed, Sutro marks the request as authenticated and forwards it to the requested endpoint.
</Check>

### Quick reference

| Check                | Requirement                                                                                       |
| -------------------- | ------------------------------------------------------------------------------------------------- |
| **JWT structure**    | Must be well-formed; malformed or missing tokens are rejected                                     |
| **Audience (`aud`)** | Must equal `"https://sapi.withsutro.com"`                                                         |
| **Issuer (`iss`)**   | Must map to a registered issuer for your organization                                             |
| **Signature**        | Must verify against the public certificate associated with the issuer                             |
| **Subject (`sub`)**  | Must resolve to a known Member or Builder belonging to your organization                          |
| **Builder mTLS**     | If the subject is a Builder, the request must arrive over mTLS with a matching client certificate |

## Next steps

Ready to set up authentication for your application? Follow our step-by-step guide to [secure your connections](/docs/getting-started/auth/how-to-secure-connections).