[Use Case] a machine-to-machine (M2M) service working across OUs

[AnuradhaSK]

Machine-to-machine (M2M) use cases such as bots, CLIs, backend or daemon processes, or any application that consumes APIs directly without user intervention are commonly handled with tokens issued through the client credentials grant flow.

In a B2B service, there can be such machine services that need to work across different organizations. A single service serving multiple organizations must be able to act against one organization's data at a time, and its access to each organization's data must be explicitly granted.

The use case, in plain terms

Two things happen together:

• An organization that owns / publishes APIs wants to open those APIs (all of them, or a chosen subset) to other organizations, so their machine services (1st party or 3rd party apps) also can consume them.
• A machine service wants to consume those APIs on behalf of one specific organization at a time using a single client id / secret pair by asking for a token that represents the organization it is acting for.
  Example: A SaaS provider offers a booking API to its business customers, each modeled as an ou(organization). The provider runs a backend service that reconciles bookings for many customer organizations. Instead of registering one application per customer, the service holds one credential and, for each run, requests a token that says "I am acting for Organization X." That token can only be used against Organization X's data. A customer could equally build its own bot that consumes the API for just its own organization.

Acceptance criteria:

• An organization can open / publish / grant its registered APIs: all of them or a subset, to other organizations, so those organizations can access them.
• A service application (bot, CLI, backend service) can be scoped to access APIs for: all organizations, a selected set of organizations, or none (only the organization it is registered in)
• The M2M service is not visible as an application inside a granted organization. Its delegated admins do not see it listed among their own organization's applications. Any user with access to a granted organization (including delegated admins) cannot modify the M2M application or the set of APIs it is authorized for. Ownership and configuration stay with the M2M application owning OU; the grant confers usage only.
• The service can use a single client id / secret pair to obtain tokens via the client credentials grant to access different organizations.
• When obtaining a token, the service can specify which organization the token is being requested for.
• The issued token indicates the organization it is granted for.
• The API gateway validates the organization the token was issued for, and validates the requested scopes against that organization.
• When an organization is granted only a subset of the API resources the M2M service is authorized for, tokens issued for that organization are limited to that subset. An org-bounded token carries only the API resources and scopes granted to that organization, never the service's full set.

References:

• Feature Request: Allow trusted machine clients to obtain an access token scoped to a chosen Organization Unit (without a per-OU application) #4037
• Auth0 capabilities: https://auth0.com/docs/manage-users/organizations/organizations-for-m2m-applications