Skip to main content

Auth Provider Types

This guide explains how to discover the supported Authentication Provider Types and retrieve their JSON Schemas so you can construct valid provider configurations.

Why this matters​

  • Each Auth Provider type (e.g., OIDC, Google, GitHub) has a distinct configuration contract.
  • Fetching the JSON Schema lets you validate payloads client-side and avoid runtime errors when creating/updating providers.
  • Schemas may evolve; always fetch the latest before rolling out changes.

Operations​

Assumptions​

- Authorization: Bearer YOUR_ACCESS_TOKEN
- Accept: application/hal+json or application/json

List auth provider types​

Request example

curl -s \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json" \
  "https://gateway.production.netfoundry.io/frontdoor/3d6d2b6e-6c7a-4a7f-8c3d-9a9d2e1f0b1c/auth-provider-types"

Response example

[
  {
    "type": "OIDC",
    "displayName": "OpenID Connect",
    "description": "Validate JWTs issued by an OpenID Connect provider"
  }
]

Get a provider type by name​

Request example

curl -s \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json" \
  https://gateway.production.netfoundry.io/frontdoor/3d6d2b6e-6c7a-4a7f-8c3d-9a9d2e1f0b1c/auth-provider-types/OIDC

Response example

{
  "type": "OIDC",
  "description": "Standard OIDC"
}

Fetch the JSON schema for a provider type​

Use this to validate the data object you send when creating or updating an Auth Provider.

Request example

curl -s \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/json" \
  https://gateway.production.netfoundry.io/frontdoor/3d6d2b6e-6c7a-4a7f-8c3d-9a9d2e1f0b1c/auth-provider-types/OIDC/schema

Response example (excerpt)

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://schemas.netfoundry.io/frontdoor/auth-providers/oidc.schema.json",
  "type": "object",
  "required": ["issuer", "clientId"],
  "properties": {
    "issuer": {"type": "string", "format": "uri"},
    "clientId": {"type": "string"},
    "audiences": {"type": "array", "items": {"type": "string"}}
  }
}

Technical Notes​

Paths​

- GET /frontdoor/\{frontdoorId\}/auth-provider-types
- GET /frontdoor/\{frontdoorId\}/auth-provider-types/{type}
- GET /frontdoor/\{frontdoorId\}/auth-provider-types/{type}/schema

Common errors​

400 Bad Request (client error)​

{
  "error": "invalid_request",
  "message": "Value for <property> must be of <type>"
}

Possible reasons include:

  • Clock skew: If tokens seem instantly expired, check system time synchronization on the machine making requests.
  • Token format: Authorization header must be exactly Authorization: Bearer <token> with a space after Bearer or Authorization: Basic <username:token> with a space after Basic and a color separator.

401 Unauthorized (missing/expired token)​

{
  "error": "unauthorized",
  "message": "Bearer token is missing or invalid"
}

Possible reasons include:

  • Clock skew: If tokens seem instantly expired, check system time synchronization on the machine making requests.
  • Token format: Authorization header must be exactly Authorization: Bearer <token> with a space after Bearer or Authorization: Basic <username:token> with a space after Basic and a color separator.

403 Forbidden (not_authorized)​

{
  "error": "not_found",
  "message": "Frontdoor 3d6d2b6e-6c7a-4a7f-8c3d-9a9d2e1f0b1c not found"
}

Possible reasons include:

  • Invalid token: The token is not valid.
  • The token does not grant access to the requested resource.
  • Clock skew: If tokens seem instantly expired, check system time synchronization on the machine making requests.
  • Token format: Authorization header must be exactly Authorization: Bearer <token> with a space after Bearer or Authorization: Basic <username:token> with a space after Basic and a color separator.