If your organisation runs its own AI gateway or internal assistant, and your users sign in to it with Microsoft Entra ID, the gateway can reach the Jiminny MCP as the signed-in user. Users do not sign in to Jiminny or authorise the connection separately. This article is for the IT or platform team that owns the gateway.

Note: This sign-in option is set up by Jiminny for each organisation on request. To ask for it, contact your Customer Success Manager or our support team.

How it works

Your gateway exchanges the user's Entra token for a short-lived Jiminny MCP access token, server to server. It uses Microsoft's On-Behalf-Of flow. There is no browser step and no consent screen for the user.

The user signs in to your gateway with Microsoft Entra ID.
Your gateway asks Entra for a token for Jiminny, on that user's behalf.
Your gateway sends that token to Jiminny, with the client credentials Jiminny gave you.
Jiminny checks the token, finds the user's Jiminny account and returns an MCP access token for that user. The token is valid for 15 minutes.
Your gateway calls the Jiminny MCP with that token, like any other MCP client.

The user's Jiminny permissions apply at all times. The gateway can only reach calls, deals and other data that the user can already see in Jiminny.

How Jiminny identifies the user

Jiminny reads the user's sign-in name from the token (the preferred_username claim). This must be exactly the user's primary email in Jiminny, and that Jiminny account must be active. Secondary emails are not checked.

In most tenants preferred_username is the user's UPN (user principal name). If your UPNs differ from your users' email addresses, for example j.smith@company.onmicrosoft.comagainst john.smith@company.com, sign-in fails for those users. See step 4 below

Setting it up

You need:

An app registration for your gateway in your Entra tenant. The gateway must be able to run the On-Behalf-Of flow: it has its own client secret or certificate, and users sign in to it with a token addressed to the gateway app.
An Entra administrator who can grant admin consent in your tenant.
An active Jiminny account for each user who will use the gateway.

Step 1 — Send Jiminny your details

Send these to your Customer Success Manager or our support team.

What we need	Where to find it
Tenant ID	Microsoft Entra admin center → Entra ID → Overview → Tenant ID
Your gateway's Application (client) ID	Entra ID → App registrations → your gateway app → Overview → Application (client) ID
The Jiminny scope your gateway already requests, if it has one	Your gateway's configuration. It ends in `access_as_user`. Skip this if you are connecting the gateway to Jiminny for the first time.
Roughly how many users will use the gateway	We set your per-minute request limit from this number

Step 2 — Receive your credentials from Jiminny

Jiminny registers your gateway and shares these with you in a secure vault your team can access:

Client ID and client secret. Your gateway uses these to authenticate to Jiminny.
Jiminny application ID and scope. The scope is what your gateway requests from Entra. It ends in access_as_user. If you sent us a scope in step 1, we confirm it or tell you which one to use instead.

Note: The client secret is shown once and Jiminny cannot retrieve it later. Store it in your secret manager. If it is lost or exposed, contact us for a new one — the old secret stops working immediately.

Step 3 — Grant admin consent to the Jiminny scope

In the Entra admin center, open App registrations → your gateway app → API permissions.
Select Add a permission → APIs my organization uses, and search for the Jiminny application ID from step 2.
Select Delegated permissions, tick access_as_user and select Add permissions.
Select Grant admin consent for your tenant.

If the Jiminny application does not appear in the search, it has not been added to your tenant yet. Contact us and we will send you a link to add it.

Note: Consent you gave earlier for Jiminny's Office 365 calendar or login integration does not cover this. Your gateway app needs its own consent to access_as_user.

Step 4 — Check your users' sign-in names match Jiminny

Make sure your gateway requests the openid and profile scopes when users sign in. Without profile, the token does not carry the user's sign-in name and Jiminny refuses it.
Compare each user's UPN with their primary email in Jiminny. Where they differ, ask your Jiminny admin or our support team to change the user's primary email in Jiminny to match the UPN.

Choosing who can use it

Entra controls which of your users can reach Jiminny through the gateway. To limit it, open Enterprise applications → your gateway app → Properties, set Assignment required to Yes, and assign the users or groups who should have access. A user also needs an active Jiminny account.

Connecting your gateway

For each signed-in user, your gateway makes two token requests, then calls the MCP.

1. Request a Jiminny token from Microsoft

Run the On-Behalf-Of exchange with the user's token for your gateway:

POST https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token Content-Type: application/x-www-form-urlencoded  grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer &client_id=<your gateway's application ID> &client_secret=<your gateway's Entra secret> &assertion=<the user's token for your gateway> &scope=<the Jiminny scope from step 2> &requested_token_use=on_behalf_of

Entra returns an access token for Jiminny.

2. Exchange it for a Jiminny MCP token

Send the Entra token to Jiminny, authenticating with the client ID and secret Jiminny gave you:

curl -u "<client_id>:<client_secret>" https://mcp.jiminny.com/mcp/oauth/token \   -d grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer \   -d assertion=<the Entra token from step 1>

A successful response looks like this:

{"token_type": "Bearer", "expires_in": 900, "access_token": "..."}

3. Call the Jiminny MCP

Send the access token as a Bearer token on requests to https://mcp.jiminny.com/mcp. Use the same address whichever Jiminny region your data is in.

Note: Jiminny does not issue a refresh token. When the access token expires after 15 minutes, repeat steps 1 and 2. Entra issues a new token without involving the user.

If a token request is refused

The token endpoint answers with a standard OAuth error. Most refusals come from the Entra token, the credentials or the user's Jiminny account.

Response	What it means	What to do
`invalid_client`	The client ID or client secret is wrong.	Check the credentials Jiminny sent you.
`invalid_grant` — "The assertion was rejected"	The Entra token did not pass verification.	Check the points below. Our support team can see the exact reason.
`invalid_grant` — "No active Jiminny account matches the asserted user"	The token is valid, but that user has no active Jiminny account with that primary email.	Ask your Jiminny admin to add or reactivate the user, or correct their primary email.
`429 temporarily_unavailable`	Your gateway reached its per-minute request limit.	Wait and retry. If your user numbers have grown, ask us to raise the limit.
`unauthorized_client`	This sign-in is switched off for your organisation.	Contact Jiminny.
`server_error`	Jiminny could not complete the request.	Retry. If it continues, contact our support team.

When the assertion is rejected, check that the token:

comes from the On-Behalf-Of exchange. The user's original sign-in token is not accepted.
was requested with the Jiminny scope from step 2.
is an access token, not an ID token.
was issued by your tenant to your gateway app, the two IDs you sent us in step 1.
carries the user's sign-in name. Your gateway must request the profile scope at sign-in.
belongs to a member of your tenant, not a guest.
has not expired.

Note: Refused requests count towards your request limit, so avoid retrying in a tight loop.

Good to know

Access is short-lived — tokens last 15 minutes and are never refreshed. If the sign-in is switched off, outstanding tokens expire within 15 minutes.
Deactivated users lose access straight away — the user's Jiminny account is checked on every token request.
Guest users are not accepted — B2B guests in your tenant sign in with an email outside your registered domains.

For what data the connector can reach and how it is protected, see Jiminny MCP - Security & Privacy.

FAQ

1. We use a different identity provider, such as Okta or Google. Can we use this?

No. This sign-in only accepts tokens issued by Microsoft Entra ID. With another identity provider, each user connects their AI tool by authorising their own Jiminny account — see Jiminny MCP.

2. Does this replace the Claude or ChatGPT connector for our users?

No. Users can keep using those connectors alongside your gateway.

3. Do users need to connect Office 365 in Jiminny first?

No. Users only need an active Jiminny account whose primary email matches their Microsoft sign-in name.

Jiminny MCP - Microsoft Entra ID sign-in