Is SNI for authorization or authentication?

学海一粟/Sticky Notes for Parents
1

:locked_with_key: Is SNI( Server Name Indication) used for authentication or authorization?

:white_check_mark: It’s related to authentication, not authorization.

:white_check_mark: Why it’s authentication:

Authentication is about verifying identity — “Who are you?”

When a browser connects to https://www.dogs.com, it expects to receive a certificate that authenticates the server as being www.dogs.com.

SNI helps the server pick the correct TLS certificate so the browser can authenticate the server’s identity.

:cross_mark: It’s not authorization because:

Authorization is about access control — “Are you allowed to do this?”

SNI doesn’t control what the user is allowed to access. It only ensures that the browser talks to the correct server and can trust it.

:brain: Summary:

Term Meaning Role in SNI use case

Authentication Verifying identity :white_check_mark: Yes — server proves its identity using TLS certificate

Authorization Granting access to resources :cross_mark: No — not involved in this process

2

How does cert based authorization work?

Certificate-based authorization builds on authentication using digital certificates, typically X.509 certificates. Here’s how it works step by step, focusing on how it goes beyond authentication to make authorization decisions:

:locked_with_key: 1. Certificate-Based Authentication

Before you can authorize, you authenticate:

  • A client (user or service) presents a digital certificate to a server.

  • The server:

    • Verifies the certificate’s validity (signature, expiration, issuer).

    • Confirms it’s from a trusted Certificate Authority (CA).

    • Optionally checks revocation status (CRL or OCSP).

This confirms the client’s identity.

:white_check_mark: 2. Certificate-Based Authorization

Once authenticated, authorization happens like this:

:small_orange_diamond: Option A: Based on certificate attributes

  • Certificates can include extensions or fields that carry identity data:

    • Common Name (CN)

    • Organization (O)

    • Organizational Unit (OU)

    • Subject Alternative Name (SAN)

    • Custom attributes (e.g., roles, group membership)

  • The server uses this info to enforce access control policies.

    Example:

    • A certificate’s OU field is Engineering, and your policy says:

      “Only users from OU=Engineering can deploy to staging.”

    • If the client cert matches, access is allowed.

:small_orange_diamond: Option B: Certificate mapped to internal roles

  • The server maps the certificate identity (e.g., subject DN or public key fingerprint) to internal roles or user accounts stored in a database or policy engine.

    Example:

    • Cert subject: CN=Alice,OU=Ops,O=MyOrg

    • Mapped in server config to role: admin

    • Policy: admin can access /secure-api.

:brain: Typical Use Cases

  • Mutual TLS (mTLS): Clients and servers both present certs.

  • Kubernetes: Uses client certs for API access control.

  • VPNs: Grant network access based on cert identity.

  • IoT: Devices identified and granted access via certs.

:prohibited: Common Misconception

  • Certificates don’t enforce authorization on their own.

    • They prove who you are.

    • You need external policy to decide what you’re allowed to do.

:locked: Tools/Tech That Use Cert-Based Authorization

  • Envoy with mTLS + RBAC

  • Istio service mesh

  • NGINX with client cert auth

  • Open Policy Agent (OPA) using cert metadata

  • AWS IoT Core (X.509 certs for device-level permissions)