Service Auth Schemes

Created: 2026-05-12 · 8 concepts

https://ontology.global.church/core#ServiceAuthSchemeScheme

Authentication mechanisms a federation service may require: None, API Key, OAuth 2.0, OpenID Connect, mutual TLS, JWT bearer, HTTP Basic, signed requests. Multi-valued on gc:OfferedService — a service may legitimately offer two auth modes (e.g., API key for simple usage and OAuth 2.0 for delegated access).

Code	Label	Definition
`SAU-APIKEY`	API Key	Static credential identifying the calling application (typically issued via a developer portal). Sent as a header (X-API-Key, Authorization: ApiKey ...) or query parameter. The dominant mechanism in the Christian-tech ecosystem (Joshua Project, YouVersion App Key, API.Bible, Bible Brain). Cheap to integrate; weak on revocation and per-user scoping.
`SAU-BASIC`	HTTP Basic	HTTP Basic authentication (RFC 7617) — username + password base64-encoded in the Authorization header. Acceptable only over TLS. Common on legacy and infrastructure endpoints (GraphDB UI, internal admin APIs); rare in modern public APIs.
`SAU-JWT`	JWT Bearer	JSON Web Token (RFC 7519) presented as a bearer credential in the Authorization header. Often the access-token format inside OAuth 2.0 / OIDC flows; sometimes used standalone with a long-lived signed JWT. Disciple.Tools's REST API is the canonical mission-tech example.
`SAU-MTLS`	Mutual TLS	Mutual TLS — both client and server present X.509 certificates during the TLS handshake. Strong authentication for service-to-service calls in trusted infrastructure (org-to-org federation backplanes). Operational overhead of certificate provisioning + rotation.
`SAU-NONE`	None / Public	Open public endpoint, no authentication required. May still rate-limit by IP. Examples: bible-api.com, public SPARQL endpoints. Use only when the resource is non-sensitive and the rate budget can absorb anonymous traffic.
`SAU-OAUTH2`	OAuth 2.0	OAuth 2.0 (RFC 6749) — delegated authorization with scoped access tokens issued by an auth server. Supports user-context flows (authorization code, device code) and machine flows (client credentials). Use when the service exposes per-user data or needs revocable scopes.
`SAU-OIDC`	OpenID Connect	OpenID Connect — identity layer built on OAuth 2.0 (https://openid.net/connect/) providing user-identity claims in addition to access tokens. Use when the service needs to know who the user is, not just what they're allowed to do.
`SAU-SIG`	Signed Request	Request-signing authentication: the client signs a canonical representation of the request (HTTP Signatures, AWS SigV4, DPoP, or ActivityPub HTTP signatures). Adds replay protection and per-request integrity without bearer tokens. Forward-looking for verifiable-credential and agentic-trust flows.