Skip to main content
This section documents the B Brands IdP — the centralized authentication platform exposed through auth.bbrands.io. It is the single place where the holding proves who a user is and whether they are enabled for a given platform (ERP, CRM, analytics, future SaaS, partners).

​
What this is

The B Brands IdP is the holding’s standard identity provider. Any platform — existing or future — authenticates its users via OAuth 2.1 / OpenID Connect against B Brands, instead of maintaining its own user database. The protocol is handled by a managed OAuth 2.1 / OIDC engine, wrapped entirely behind the per-environment auth.* origin. Clients never see the underlying engine: client registration, identity lifecycle, audit and every public endpoint live in the B Brands identity layer. The engine is a replaceable implementation detail.

​
The golden rule: the IdP authenticates, it does not authorize

This is the single most important concept for every team integrating with the IdP. Keep it in mind while reading the rest of the section.

What the IdP does

Proves a user’s identity (sub, email, profile), delivers their business-account context (https://bbrands.io/profile: primary account and its external system id) and whether they are enabled for a platform (active / suspended / revoked).

What the IdP does NOT do

It does not manage application permissions. Each client application decides what a user can do inside it. There is no central permission catalogue.
There are two directions of calls, treated differently:
1

A user signs into a client app via B Brands

The IdP only authenticates. The client app authorizes its own users with its own roles/groups.
2

A client app consumes the B Brands APIs

B Brands protects its own data with the existing internal RBAC. The client acts with an internal B Brands JWT obtained through the token exchange (user context) or with an existing API key (machine-to-machine, no user).
The OAuth ES256 token never reaches the B Brands business APIs. Those APIs keep validating the internal HS256 JWT exactly as they do today. The Resource Server does not change.

​
Two token formats coexist

The two never mix: ES256 for identity towards clients, HS256 for consuming the B Brands APIs. See Security for the full token model.

​
Who should read what

Integrators (new platform)

Configure your OAuth client, discovery, redirect URIs and (optionally) the token exchange to call B Brands APIs.

Backend / architects

Component layers, the engine facade, ADRs and the access-token hook.

Backend / integrators

The OAuth / OIDC endpoint contract: discovery, authorize, token, userinfo, revoke.

Security / compliance

Token model, secret management, threat model, revocation levels and audit.

Data / lifecycle

The identity entities, enablement lifecycle and the kill switch.

Frontend teams

The separate end-user social login through the managed engine.

​
Environments

The IdP runs in multiple environments. Each has its own isolated engine, its own issuer and its own registered OAuth clients. A token minted in one environment is never valid in another, because clients validate the iss of their own environment. Every OAuth/OIDC surface — discovery, JWKS, authorize, token, userinfo, revoke and the interactive consent/login UI — lives under the same per-environment auth.* origin. That origin is the canonical issuer embedded in every issued token.
A single user-facing identity origin, on purpose: auth.* is the canonical issuer and serves every protocol endpoint plus the consent UI (same shape as accounts.google.com). The api.* domain hosts the underlying implementation and the B Brands business APIs, but it is not the advertised issuer — clients only ever configure auth.*. See Architecture for the decision record.

​
Client naming convention

OAuth client identifiers follow the <platform>-<environment> pattern, e.g. erp-prod, erp-cert, erp-dev. Always register a distinct client per environment.