# Authorization

Managed scheduling acts on a Cronofy Organizational Unit: its members, their
connected calendars and the scheduling rules set up in Cronofy. Your
application therefore authorizes against the Organizational Unit rather than
against individual calendars.

<table class="table--definitions">
	<thead>
			<tr>
					<th>Method</th>
					<th>When it fits</th>
			</tr>
	</thead>
	<tbody>
			<tr>
					<td>[Managed Organizational Unit](https://docs.cronofy.com/developers/managed-scheduling/managed-organizational-units/index.md)</td>
					<td>Your application provisions an Organizational Unit for each customer and runs scheduling for them. Provisioning returns an access token with the `organizational_unit_scheduling` scope, as if the customer had authorized through Organization Connect.</td>
			</tr>
			<tr>
					<td>[Internal Application](https://docs.cronofy.com/api-reference/application-management/internal-applications/index.md)</td>
					<td>Your application serves one Organizational Unit, typically your own company's. Authenticate with the application's `client_secret`; no OAuth flow is needed.</td>
			</tr>
			<tr>
					<td>[Organization Connect](https://docs.cronofy.com/developers/temporal-grid/connectivity/organization-connect/index.md)</td>
					<td>Your application serves many customers, each with their own Organizational Unit. Each customer authorizes your application, for example with the `organizational_unit_scheduling` scope.</td>
			</tr>
			<tr>
					<td>[User impersonation](https://docs.cronofy.com/api-reference/authorization/authentication/index.md)</td>
					<td>You need to act as a specific member of the Organizational Unit. Pass their `sub` in the `Cronofy-Impersonate` header alongside either of the above.</td>
			</tr>
	</tbody>
</table>
## Embedded Scheduler
The Scheduler embed authenticates in the browser with an Embed Token, a JWT
your server signs with the application's Embed Secret. See
[Embed authentication](https://docs.cronofy.com/api-reference/authorization/embed-authentication/index.md)
for generating tokens, and
[Onboarding users](https://docs.cronofy.com/api-reference/managed-scheduling/embedded-scheduler/onboarding-users/index.md)
for passing one through sign up.

## MCP Server
The [MCP Server](https://docs.cronofy.com/developers/temporal-grid/mcp-server/index.md)
accepts an Internal Application's `client_secret`, or takes users through an
OAuth 2.0 flow for a standard application.


---
[Read in HTML](https://docs.cronofy.com/developers/managed-scheduling/authorization/)
Method	When it fits
[Managed Organizational Unit](https://docs.cronofy.com/developers/managed-scheduling/managed-organizational-units/index.md)	Your application provisions an Organizational Unit for each customer and runs scheduling for them. Provisioning returns an access token with the `organizational_unit_scheduling` scope, as if the customer had authorized through Organization Connect.
[Internal Application](https://docs.cronofy.com/api-reference/application-management/internal-applications/index.md)	Your application serves one Organizational Unit, typically your own company's. Authenticate with the application's `client_secret`; no OAuth flow is needed.
[Organization Connect](https://docs.cronofy.com/developers/temporal-grid/connectivity/organization-connect/index.md)	Your application serves many customers, each with their own Organizational Unit. Each customer authorizes your application, for example with the `organizational_unit_scheduling` scope.
[User impersonation](https://docs.cronofy.com/api-reference/authorization/authentication/index.md)	You need to act as a specific member of the Organizational Unit. Pass their `sub` in the `Cronofy-Impersonate` header alongside either of the above.