# 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](https://m7.org/docs/api/api.user.m7.org/org.md) and [bound access-token requirements](https://m7.org/docs/api/api.user.m7.org/authorization.md).

## 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 |

```json
{
  "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](https://m7.org/docs/api/sso.user.m7.org/browser-direct)
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.

```json
{
  "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](https://m7.org/docs/api/api.user.m7.org/tenant-member-security.md) 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](https://m7.org/docs/api/sso.user.m7.org/browser-direct#errors-and-troubleshooting).

## 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](https://m7.org/docs/api/api.user.m7.org/tenant-member-security.md).
See [the authority matrix](https://m7.org/docs/api/api.user.m7.org/org.md#organization-roles) and
[upgrade order](https://m7.org/docs/api/api.user.m7.org/organization-upgrade.md).