Auth preview

Issuer-bound
Auth design.

Review the partner challenge and callback contract. Production token issuance is disabled until a trusted identity issuer is integrated.

Review API Auth docs
Planned sequence
01

Issue

A trusted issuer creates a credential bound to its provenance.

02

Challenge

The partner creates a short-lived challenge through the API.

03

Verify

OTRUST verifies credential ownership and challenge binding.

04

Callback

The user returns to the registered callback with token and state.

Production requirements

Designed,
not launched.

The interface is reviewable, while production challenges fail closed without trusted credential provenance.

Visible domain

The OTRUST domain remains visible during verification.

Safe branding

Partner branding cannot inject JavaScript.

Bound callbacks

Callbacks must preserve challenge, state, redirect URI, and expiry.

Provider-neutral integration contract

OTRUST can become the visible credential and callback layer after a trusted issuer is integrated. The issuer, credential binding, and OTRUST processing boundary must remain explicit.

Issuer integration comes first

Challenge binding and branding do not establish identity. A production launch requires credential issuance from an accountable external provider.

Planned identity-provider boundary

The credential issuer must be identified and preserved through token verification.

Provider-agnostic contract

The API does not assume one issuer, but it rejects records without trusted issuer binding.

Visible processing boundary

OTRUST remains visible during hosted processing, with DPO contact and auditability intact.

Read Auth Docs

Developer integration

This is the planned server-side integration. Do not ship it until health reports the trusted issuer capability as enabled.

Create a challenge

import { auth } from '@otrust/sdk'

const state = auth.generateState()
const challenge = await auth.createChallenge({
  clientId: 'my-app',
  redirectUri: 'https://app.example/auth/callback',
  scope: ['identity'],
  state
})

if (challenge.ok) {
  res.redirect(challenge.value.loginUrl)
}

Verify the callback

const token = req.query.token
const result = await auth.verify(token)

if (result.ok && result.value.valid) {
  const proofId = result.value.proofId
  const verified = result.value.identity?.verified
}
Production challenge creation currently returns 503 trusted_identity_issuer_required. Direct login visits cannot bypass that gate.

Partner branding

The preview supports review of approved partner colors and copy per clientId. Branding does not activate credential issuance or token creation.

Save a theme

PUT /admin/auth-branding/hemsted_prod
X-Admin-Key: <admin-key>

{
  "logoUrl": "https://hemsted.se/assets/branding/logo.svg",
  "backgroundColor": "#FAFAF7",
  "primaryColor": "#0F1B2D",
  "textColor": "#0F1B2D",
  "fontFamily": "Inter",
  "borderRadius": 8,
  "spacingScale": "default",
  "headline": "Sign in to Hemsted",
  "subhead": "Issuer-bound credential required",
  "footerText": "Hemsted AB integration preview by OTRUST",
  "autoRedirectSeconds": 3
}

Brand-guide checklist

  • Logo must be served over HTTPS and stay below 200KB.
  • Colors are validated as hex, rgb, or rgba values.
  • Copy is rendered as text only, never as injected HTML.
  • The theme follows a future hosted credential flow after issuer integration.
  • Every change is written to the OTRUST audit log with client_id, actor, fields, and timestamp.