Skip to main content
This operator sign-in path is available in source builds. It is not part of the published 0.1.4 SDK and CLI or the current hosted release.
Deploying an application and running its business operations are separate permissions. The CLI and console authenticate business requests as a user. The application’s grants, data rules and approvals decide what that user may do. An administrator key cannot invoke an operation or impersonate its caller.

Trust your team’s identities

Add the management identity provider explicitly:
bijection/auth.config.ts
Keep any existing application providers in the array. New managed deployments receive 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. Verified identity on the Operations page Open Manage operation permissions to check, grant or revoke 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. Operation permission editor If an update’s outcome is uncertain, choose Check status before retrying it.

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
Select exactly one provider. Register authorization-code flow with PKCE S256, the exact HTTPS console callback, and the native client’s 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.
The console offers Sign in to your staff provider. Both clients verify the returned token through the deployment and keep the exact issuer and subject on renewal. A refused staff login never falls back to a management identity. --member is a management-team lookup and is unavailable for this provider; use --me or the exact staff token identifier instead. Staff provider sign-in

Identity and lifetime

Management identities have a stable subject such as member_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.