Discovery

Point an OIDC client at haunt.gg and let it configure itself.

The OpenID Connect discovery document. Most OIDC libraries only need the issuer https://haunt.gg and will find this on their own — you rarely have to fetch it by hand.

GET/.well-known/openid-configuration

The RFC 8414 path serves the same document:

GET/.well-known/oauth-authorization-server

The issuer is https://haunt.gg, but the endpoints themselves live under https://haunt.gg/api/auth/…. That is normal and the discovery document says so — configure your client with the issuer and let it read the rest from here. There is no copy of this document under /api/auth/.well-known/.

Example Request

Request
curl "https://haunt.gg/.well-known/openid-configuration"

Response

Response
Cached for 5 minutes (Cache-Control: public, max-age=300). Note what is absent: there is no registration_endpoint, because apps are registered in the dashboard rather than dynamically.
{
  "issuer": "https://haunt.gg",
  "authorization_endpoint": "https://haunt.gg/api/auth/oauth2/authorize",
  "token_endpoint": "https://haunt.gg/api/auth/oauth2/token",
  "userinfo_endpoint": "https://haunt.gg/api/auth/oauth2/userinfo",
  "revocation_endpoint": "https://haunt.gg/api/auth/oauth2/revoke",
  "introspection_endpoint": "https://haunt.gg/api/auth/oauth2/introspect",
  "end_session_endpoint": "https://haunt.gg/api/auth/oauth2/end-session",
  "jwks_uri": "https://haunt.gg/api/auth/jwks",
  "scopes_supported": [
    "openid",
    "identify",
    "email",
    "connections",
    "offline_access"
  ],
  "response_types_supported": ["code"],
  "response_modes_supported": ["query"],
  "grant_types_supported": [
    "authorization_code",
    "client_credentials",
    "refresh_token"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "revocation_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "introspection_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post"
  ],
  "code_challenge_methods_supported": ["S256"],
  "subject_types_supported": ["public"],
  "id_token_signing_alg_values_supported": ["EdDSA"],
  "authorization_response_iss_parameter_supported": true,
  "prompt_values_supported": [
    "login",
    "consent",
    "create",
    "select_account",
    "none"
  ],
  "acr_values_supported": ["urn:mace:incommon:iap:bronze"],
  "claims_supported": [
    "sub",
    "iss",
    "aud",
    "exp",
    "iat",
    "sid",
    "scope",
    "azp",
    "name",
    "preferred_username",
    "picture",
    "profile",
    "email",
    "email_verified",
    "uid",
    "connections"
  ]
}

Two entries you should ignore

The document is generated by the provider library and advertises two things haunt.gg apps cannot actually use:

  • client_credentials in grant_types_supported — haunt.gg apps are registered for authorization_code and refresh_token only, so this grant always answers unauthorized_client.
  • end_session_endpoint and select_account in prompt_values_supported — RP-initiated logout and account selection are not enabled for haunt.gg apps. Sign the user out inside your own app instead.

Two claims in claims_supported are likewise never emitted for a haunt.gg app: sid (it belongs to the end-session feature) and azp.

JSON Web Key Set

GET/api/auth/jwks

The public keys that verify id_token signatures. Ed25519 / EdDSA. Any OIDC library will fetch and cache this for you from jwks_uri.

Response
Key set. Match the id_token header's kid against these entries.
{
  "keys": [
    {
      "kty": "OKP",
      "crv": "Ed25519",
      "alg": "EdDSA",
      "kid": "3f1c…",
      "x": "11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"
    }
  ]
}