(require '[supabase.core.client :as client]
         '[supabase.auth :as auth])

(def c (client/make-client "https://abc.supabase.co" "anon-key"))

(auth/sign-up c {:email "user@example.com" :password "secure-password"})
(auth/sign-in-with-password c {:email "user@example.com" :password "secure-password"})

Authentication and user management against Supabase Auth.

Supports password, OAuth, OTP, SSO, ID-token, Web3 and anonymous sign-in,
user retrieval and sign-up, the full session/identity lifecycle
(`verify-otp`, `refresh-session`, `update-user`, `resend`,
`reset-password-for-email`, `exchange-code-for-session`, `reauthenticate`,
`get-claims`, identity linking) and server observability
(`get-server-health`, `get-server-settings`).

See `supabase.auth.admin` for the service-role admin API.

## Example

    (require '[supabase.core.client :as client]
             '[supabase.auth :as auth])

    (def c (client/make-client "https://abc.supabase.co" "anon-key"))

    (auth/sign-up c {:email "user@example.com" :password "secure-password"})
    (auth/sign-in-with-password c {:email "user@example.com" :password "secure-password"})

Each function returns `{:status :body :headers}` on success or an anomaly
map on failure. See https://supabase.com/docs/reference/javascript/auth-api

(require '[supabase.core.client :as client]
         '[supabase.auth.admin :as admin])

(def c (client/make-client "https://abc.supabase.co" "service-role-key"))

(admin/create-user c {:email "user@example.com" :password "secret"
                      :email-confirm true})
(admin/list-users c {:page 1 :per-page 50})

Server-side admin operations against the Supabase Auth API.

Every function here requires a `client` configured with the project's
**service-role** key (not the anon key) as its access token — these
endpoints bypass Row-Level Security and must never be exposed to a browser.

## Example

    (require '[supabase.core.client :as client]
             '[supabase.auth.admin :as admin])

    (def c (client/make-client "https://abc.supabase.co" "service-role-key"))

    (admin/create-user c {:email "user@example.com" :password "secret"
                          :email-confirm true})
    (admin/list-users c {:page 1 :per-page 50})

Each function returns `{:status :body :headers}` on success or an anomaly
map on failure. See https://supabase.com/docs/reference/javascript/auth-admin-api

(require '[supabase.core.client :as client]
         '[supabase.auth.admin.custom-providers :as providers])

(def c (client/make-client "https://abc.supabase.co" "service-role-key"))

(providers/create-provider c {:provider-type "oidc"
                              :identifier "acme"
                              :name "Acme SSO"
                              :client-id "client-id"
                              :client-secret "client-secret"
                              :discovery-url "https://sso.acme.com/.well-known/openid-configuration"})
(providers/list-providers c)

Custom OAuth2 / OIDC provider administration against the Supabase Auth API.

Registers and manages identity providers beyond the built-in social login
list, e.g. a private OIDC issuer or a partner's OAuth2 server.

Like the rest of `supabase.auth.admin`, every function requires a client
configured with the project's **service-role** key.

## Example

    (require '[supabase.core.client :as client]
             '[supabase.auth.admin.custom-providers :as providers])

    (def c (client/make-client "https://abc.supabase.co" "service-role-key"))

    (providers/create-provider c {:provider-type "oidc"
                                  :identifier "acme"
                                  :name "Acme SSO"
                                  :client-id "client-id"
                                  :client-secret "client-secret"
                                  :discovery-url "https://sso.acme.com/.well-known/openid-configuration"})
    (providers/list-providers c)

Each function returns `{:status :body :headers}` on success or an anomaly
map on failure.

(require '[supabase.core.client :as client]
         '[supabase.auth.admin.oauth :as oauth])

(def c (client/make-client "https://abc.supabase.co" "service-role-key"))

(oauth/create-client c {:client-name "my-app"
                        :redirect-uris ["https://app.example.com/cb"]})
(oauth/list-clients c)

OAuth 2.1 client administration against the Supabase Auth API.

Manages the OAuth clients registered on the project (dynamic client
registration), used when the Supabase project acts as an OAuth
authorization server.

Like the rest of `supabase.auth.admin`, every function requires a client
configured with the project's **service-role** key.

## Example

    (require '[supabase.core.client :as client]
             '[supabase.auth.admin.oauth :as oauth])

    (def c (client/make-client "https://abc.supabase.co" "service-role-key"))

    (oauth/create-client c {:client-name "my-app"
                            :redirect-uris ["https://app.example.com/cb"]})
    (oauth/list-clients c)

Each function returns `{:status :body :headers}` on success or an anomaly
map on failure.

Local JWT decoding and asymmetric signature verification for Supabase Auth.

Supabase issues JWTs signed with either a symmetric secret (`HS256`, the
legacy default — not verifiable client-side) or an asymmetric key
(`RS256` / `ES256`). For asymmetric algorithms the public keys are
published at `<auth-url>/.well-known/jwks.json`; this namespace fetches
and caches that JWKS and verifies signatures using the JDK's built-in
crypto, with no third-party dependency.

Callers should use [[supabase.auth/get-claims]] rather than these helpers
directly.

(require '[supabase.auth.mfa :as mfa])

;; 1. enroll — body carries the QR code / secret to show the user
(mfa/enroll client token {:factor-type "totp" :friendly-name "authenticator"})

;; 2. user scans the QR and types the 6-digit code
(mfa/challenge-and-verify client token factor-id "123456")

Multi-factor authentication against Supabase Auth.

Supports TOTP (authenticator apps), phone (SMS / WhatsApp) and WebAuthn
factors. Every function acts on behalf of the signed-in user identified
by `access-token` — the JWT from an active session.

The usual TOTP flow:

    (require '[supabase.auth.mfa :as mfa])

    ;; 1. enroll — body carries the QR code / secret to show the user
    (mfa/enroll client token {:factor-type "totp" :friendly-name "authenticator"})

    ;; 2. user scans the QR and types the 6-digit code
    (mfa/challenge-and-verify client token factor-id "123456")

Phone and WebAuthn factors need the explicit `challenge` + `verify`
round-trip since the response arrives out of band.

Each function returns `{:status :body :headers}` on success or an anomaly
map on failure. See https://supabase.com/docs/guides/auth/auth-mfa

(require '[supabase.auth.ring :as auth.ring])

(def app
  (-> handler
      (auth.ring/wrap-authentication client {:required? true})))

;; downstream handlers read the verified identity:
(defn handler [request]
  (let [user-id (get-in request [:supabase/claims :sub])]
    ...))

Ring middleware for Supabase Auth JWT verification.

Verifies the bearer token on incoming requests via
[[supabase.auth/get-claims]] (local JWKS verification for asymmetric
algorithms, server-side check for HS256) and attaches the verified claims
to the request map. Depends only on the Ring request/response map shape,
not on Ring itself.

## Example

    (require '[supabase.auth.ring :as auth.ring])

    (def app
      (-> handler
          (auth.ring/wrap-authentication client {:required? true})))

    ;; downstream handlers read the verified identity:
    (defn handler [request]
      (let [user-id (get-in request [:supabase/claims :sub])]
        ...))

Malli schemas for Supabase Auth entities and operations.

Used internally to validate API responses and operation inputs.
Schemas follow the Supabase Auth API specification:
https://supabase.com/docs/reference/javascript/auth-api