Browser-direct and tenant member policy
Organization and application configuration use API User's existing management authorization, scopes and normal response envelope. The browser-direct service enforces these settings; a front-end switch is not an authorization decision. See organization authority and bound access-token requirements.
Configure and inspect
Method / path below https://api.user.m7.org/api/v2 |
Scope | Input and result |
|---|---|---|
POST /org/get |
org.get |
id organization UUID; returns organization including config,knobs |
POST /org/set_knobs |
org.set_knobs |
id plus changed policy fields; comment: SET_KNOBS, updated org/config/knobs |
POST /oauth/clients/view |
oauth.clients.view |
Application record id; returns configuration |
POST /oauth/clients/set_knobs |
oauth.clients.set_knobs |
Application record id, changed fields, optional required config_lock_hash; comment: SET_KNOBS, updated app/config/knobs |
The application record ID is not its public OAuth client_id. Omitted fields
are preserved. Existing app configuration locks and ownership checks still
apply. These general configuration routes retain their documented eligible
human/machine authority; do not copy the narrower human-only member-security
route rule to them. Third-party route scopes and the existing first-party scope
exception do not replace ownership or current Management membership.
Use JSON booleans. The boolean parser also accepts integer 0/1 and
case-insensitive string 0,false,no,off / 1,true,yes,on; other values fail.
An application browser-direct value of null or empty string removes that override
and restores inheritance. Organization boolean values require an explicit value;
null/empty string is not a way to clear these security switches through this API.
Errors use the normal unsuccessful API envelope and diagnostic comment, not
stable browser-direct OAuth error names. A stale lock, unsupported app field,
invalid boolean or lost management authority must be surfaced, then reloaded.
Browser-direct application allowances
| Exact field | Default and resolution | Effect |
|---|---|---|
tenant_policy_allow_browser_direct_authentication |
Off; org → explicit app override; no consumer inheritance | Enables browser-direct authentication/session/member operations |
tenant_policy_allow_browser_direct_registration |
Off; org → explicit app override; no consumer inheritance | Enables signup family, subject to global/effective hosted registration policy |
tenant_policy_allow_browser_direct_email_signin |
Off; org → explicit app override; no consumer inheritance | Enables email sign-in when browser-direct authentication is also allowed |
{
"id":"aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa",
"tenant_policy_allow_browser_direct_authentication":true,
"tenant_policy_allow_browser_direct_registration":true,
"tenant_policy_allow_browser_direct_email_signin":true
}
Send to org/set_knobs for organization defaults or oauth/clients/set_knobs for an app override with the appropriate ID. It neither converts the ordinary token endpoint to a public client nor turns off mandatory browser-direct DPoP.
General registration/federation/branding knobs retain their existing
consumer → organization → application resolution where applicable. Public
signup additionally requires the global public-registration gate and effective
tenant_policy_hosted_allow_public_registrations. Federation requires its global
gate and effective tenant_policy_allow_federated_signin; it applies to provider
sign-in, signup and linking. Enabling only a browser-direct switch cannot bypass
these global gates. Signup activation defaults to email verification; unsupported
required phone combinations fail configuration instead of bypassing proof.
Use the browser-direct setup guide
for exact callbacks, scopes, audiences and login/registration groups.
Org-only member security switches
All three keys below default OFF when absent, read only from the organization, and have no consumer inheritance and no application override. App set_knobs rejects them even if the submitted value is false or null. The organization editor returns the effective false default in its knob projection while the stored config can remain sparse.
| Exact field | Off | On |
|---|---|---|
tenant_policy_allow_multiple_linked_identities |
Allows first federated identity; blocks additional links; existing multiple links remain usable | Allows additional provider links up to the implemented limit of 16 |
tenant_policy_allow_two_factor |
Blocks member enrollment, local factor use and factor changes; retains enrollment, backup codes and saved preferences | Restores use of enrolled factors on applicable paths; permits enrollment |
tenant_policy_allow_email_two_factor |
Local email-sign-in factor use unavailable; saved preference retained | Email factor applies only with main allowance, enabled enrollment and saved email_logins: true |
Password and email are not counted as federated links. Turning multiple-link allowance off does not delete excess links or disable their sign-in. Existing verified links are not evidence that another link can now be added.
{
"id":"aaaaaaaa-aaaa-4aaa-8aaa-aaaaaaaaaaaa",
"tenant_policy_allow_multiple_linked_identities":false,
"tenant_policy_allow_two_factor":true,
"tenant_policy_allow_email_two_factor":true
}
Send this only to POST /org/set_knobs. A successful configuration save does
not create an authenticator, issue backup codes, revoke sessions or perform a
manager reset. There is no require-enrollment mode. Authorized managers can
reset retained factors while allowances are off.
Email preference changes are unavailable while the relevant allowance is off;
turning an org allowance off never overwrites the saved member preference.
Brokered/federated authentication never requires local tenant 2FA, regardless of these switches. The broker owns that responsibility. Tenant password-based Device Code approval uses tenant password enforcement. Existing authenticated sessions, refreshes and remembered-account switches retain their established no-new-factor behavior while normal admission checks continue.
Concurrency, persistence and troubleshooting
Org configuration saves are atomic: readers see the old complete configuration or the new one, not an intermediate missing row that looks default-off. A failed policy read must propagate as a failure, not a permissive/default-off decision. Invalid stored member-security values resolve off; that is distinct from a read failure. Save responses and subsequent get/view are the way to confirm an uncertain request. Repeating the same reviewed values is safe only while the caller still intends them; reload to avoid overwriting another manager's change.
Pending signup, provider linking and factor operations recheck current policy, membership and context before insertion/session creation. Starting while allowed does not reserve authority after a switch is turned off. Unrelated setting saves must preserve these fields. Current-session UI may show retained enrollment even when effective use is unavailable: display both states instead of “not enrolled.”
Missing controls in an app editor are expected for org-only switches. A failed browser-direct request after enabling them can still reflect disabled app/org, missing authentication gate, global federation/registration denial, wrong origin, scope/audience, group admission or token binding. Follow the service's troubleshooting guide.
Organization authority
Reading own org properties/permissions uses current Management access. Changing org policy or organization-owned app policy requires the stored owner role; admin/member access alone is insufficient. Owner/admin tenant administration is a separate boundary, with human-only member security operations. See the authority matrix and upgrade order.