Trust your team’s identities
Add the management identity provider explicitly:bijection/auth.config.ts
BIJECTION_IDENTITY_ISSUER and BIJECTION_IDENTITY_AUDIENCE from their
installation. For an existing managed deployment, first run
bijection deployment configure-identity --deployment <deployment> to set and
verify these public values through management. Repeating the command is safe
after an interrupted response. The audience identifies the logical deployment;
copying another deployment’s audience is incorrect.
Trusting the provider authenticates its members. It gives them no operation
grant or staff membership in your application. Check rules that previously
treated every signed-in user as a customer before adding another issuer.
After signing in with bijection login, an administrator can grant their own
verified identity access:
--me selects your verified subject; setting the grant still requires deployment
administration. Grant someone else access with their exact issuer|subject, or
use --member person@example.com for an active verified member of your team.
The email lookup returns an identity, never that person’s token.
Manage permissions in the console
The Operations page displays the verified identity used for business requests.
read, invoke
or preview for an exact user token identifier and operation. read is required
alongside either execution permission. These changes require deployment
administration and do not change the identity used to run operations.

Use your application’s staff provider
When staff already sign in through your application’s OIDC provider, mark that same public client for CLI and console sign-in:bijection/auth.config.ts
http://127.0.0.1:<ephemeral-port>/business-auth-callback loopback redirect.
The browser also needs the provider’s discovery and token endpoints to allow
the console origin. No client secret belongs in this declaration or the CLI.
Use the same client as the app so providers using pairwise subjects do not
give the person a different subject. A provider that cannot support these
public-client flows cannot serve this sign-in path.
--member is a management-team lookup and is unavailable for this provider;
use --me or the exact staff token identifier instead.

Identity and lifetime
Management identities have a stable subject such asmember_42. Rules see the
ordinary ctx.auth.getUserIdentity() and its tokenIdentifier, for example
https://brain.bijection.com|member_42. Email and name are display data, not
identity or authority. Email is included only after provider verification.
Applications that accept multiple identities for one person should use an
explicit, authorized association table; matching email addresses never links
accounts automatically.
Management tokens live at most five minutes and never outlive their originating
credential. Every issuance rechecks membership and access. Already issued tokens
verify offline until expiry; upstream revocation also depends on the identity
provider’s propagation and the broker’s bounded observation cache. Issuance
needs the management service, and new-key verification needs its public key
endpoint. Customer-provider lifetimes and refresh availability belong to that
provider.
The CLI refreshes its user token while following a request. Refresh preserves
the caller; it does not extend authority retained by accepted external work.
Use explicit reauthorization
when that work needs fresh authority. CLI logout removes local identity caches;
console logout clears staff sessions in that tab. Neither revokes a token that
has already been issued.
Branches use the parent’s user authentication and separate branch admission.
There is no branch token audience to configure. Automation and deployment keys
cannot exchange into a person’s business identity.