FruxonDocs
ApiTrust anchors

Creates a trust anchor.

The kind decides the required fields and is immutable afterwards: `HMAC_SECRET` needs the signing secret; `OIDC_ISSUER` needs an HTTPS issuer and a pinned, non-wildcard audience — every Firebase project's tokens are signed by the same Google keys, so an unpinned audience would accept the whole internet.

POST
/v1/tenants/{tenant}/trustAnchors

Authorization

Bearer
AuthorizationBearer <token>

JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.

In: header

Path Parameters

tenant*string

The tenant identifier

Request Body

The anchor to create.

name?string
kind?string

How an Fruxon.Model.TrustAnchors.IdentityTrustAnchor verifies an identity assertion (design jit-provisioning.md §4). Two mechanisms, one architecturally important difference: HMAC needs the host's backend in the loop (it holds the secret, so it implicitly decides who gets a signed assertion at all), while an OIDC ID token is held by the client — a desktop app can hand its Firebase token straight to Fruxon with no host backend involved.

Value in"UNSPECIFIED" | "HMAC_SECRET" | "OIDC_ISSUER"
secret?string|null

HMAC only: the signing secret, write-only.

issuer?string|null
audience?string|null
environmentClaim?string|null
allowedSignInProviders?|null
[key: string]?never

Response Body

curl -X POST "https://api.fruxon.com/v1/tenants/string/trustAnchors" \  -H "Content-Type: application/json" \  -d '{}'
{
  "id": "00000000-0000-0000-0000-000000000000",
  "name": "string",
  "kind": "HMAC_SECRET",
  "hasSecret": false,
  "issuer": "string",
  "audience": "string",
  "environmentClaim": "string",
  "allowedSignInProviders": [
    "string"
  ],
  "createdAt": 0,
  "modifiedAt": 0
}
{
  "type": "string",
  "title": "string",
  "status": 0,
  "detail": "string",
  "instance": "string",
  "property1": null,
  "property2": null
}
Empty
Empty