Authentication

Every request carries a bearer token. There are two kinds, and the platform never confuses them: a human request presents an OIDC token from the configured issuer, and a machine integration presents a Baobyte service credential.

Human requestsPermalink to this section

The identity provider says who the caller is. The platform decides what they may do. That split is deliberate — delegating authentication to an established provider is standard practice, and delegating authorization would mean an external system holding the separation-of-duties rules that an AML programme is examined on.

Machine credentialsPermalink to this section

Authorization: Bearer bby_sa_v1.<tenant-uuid>.<credential-uuid>.<random-secret>

  bby_sa_v1        version prefix; routes the credential to machine handling
  tenant-uuid      non-secret; identifies the tenant
  credential-uuid  non-secret; identifies the service account
  random-secret    256 bits of randomness — this is the secret

This is intentionally not an OAuth client-credentials flow. Baobyte is not an external authorization server, and presenting one would invite integrators to treat it as a general-purpose identity provider. The routing UUIDs are not secret; the random suffix is.

Tenant resolutionPermalink to this section

In the hosted deployment the tenant comes from the subdomain, so a request to acme.aml.baobyteconsulting.com resolves to the acme tenant before any handler runs. The resolved tenant is set on the database session, which is what row-level security reads. A request resolving to no tenant is refused rather than defaulted.

Step-up authenticationPermalink to this section

Some operations require re-authentication at the moment they are performed rather than relying on a session established earlier — reading encrypted identifiers and administrative changes are the common cases. A request that needs step-up and does not have it is refused with a problem type naming the requirement, so a client can prompt rather than guess.