Sign in to a Privasys app with your Microsoft Entra tenant

By default, a Microsoft sign-in on a Privasys app goes through the Privasys app registration. An organisation can bring its own instead: your staff then authenticate through an application registered in your tenant, under your consent policy and your Conditional Access rules.

You do this once per sign-in client. It takes about twenty minutes and needs:

• the role to register applications and grant tenant-wide admin consent (Cloud Application Administrator or higher);
• the CLI, signed in as an owner of the account holding the sign-in client;
• the sign-in client's id, shown when the client was created.

1. Create the app registration

In the Entra admin centre, open Identity > Applications > App registrations > New registration.

• Name: what your users will see on the consent and sign-in pages.
• Supported account types: this decides who can sign in.

• Redirect URI: platform Web, value https://privasys.id/auth/social/callback.

Note the Application (client) ID and the Directory (tenant) ID from the overview page.

2. Register the federation and get the certificate

The preferred credential is a certificate. Privasys ID generates the key pair and keeps the private key; each sign-in's token request is signed with it, and only the public certificate is ever shared.

privasys oauth-clients federation set <sign-in-client-id> microsoft \
  --tenant <directory-tenant-id> \
  --client-id <application-client-id> \
  --display-name "Your Organisation" \
  --certificate

The command prints the public certificate and its expiry. Save the certificate as privasys-id.pem.

--display-name is the name on the sign-in button: "Sign in with Your Organisation".

3. Upload the certificate

In your app registration, open Certificates & secrets > Certificates > Upload certificate and choose privasys-id.pem.

If your policy requires a client secret instead, create one under Client secrets and pass it on standard input, so it never reaches a command line or an email:

privasys oauth-clients federation set <sign-in-client-id> microsoft \
  --tenant <directory-tenant-id> \
  --client-id <application-client-id> \
  --display-name "Your Organisation" \
  --client-secret-stdin < secret.txt

It is encrypted before it is stored, decrypted only inside a token exchange, and never returned by any listing. A secret needs you to rotate it by hand, which is why the certificate comes first.

4. Grant the API permissions

Under API permissions, add these Microsoft Graph delegated permissions: openid, email, profile and User.Read. Then choose Grant admin consent for your organisation, so your staff never see a consent prompt.

For a multi-tenant registration, also open Token configuration > Add optional claim, choose token type ID, and add xms_edov (if it is not listed, set it in the Manifest under optionalClaims.idToken). It tells Privasys ID the address is on a domain the person's tenant has verified.

5. Check it works

Open the app and sign in. The button now reads "Sign in with Your Organisation" and takes you to your tenant's sign-in page.

privasys oauth-clients federation show <sign-in-client-id>

lists the registration, its tenant and when its certificate expires.

Your sign-in logs in Entra show the application by the name you gave it. To go back to the Privasys registration at any moment:

privasys oauth-clients federation remove <sign-in-client-id> microsoft

Entra controls that work unchanged

Everything Entra applies to an application applies here, since the sign-in is yours:

• Conditional Access and MFA: target the application by name.
• Who may sign in: under Enterprise applications, set Assignment required and assign the users and groups allowed to reach the app.

Renewing the certificate

The certificate lasts two years. Before it expires, run the set command from step 2 again. It generates a new key pair and prints the new certificate, and the old key keeps signing every sign-in in the meantime. Upload the new certificate alongside the old one, then:

privasys oauth-clients federation confirm-rotation <sign-in-client-id> microsoft

The new key starts signing and the old one is destroyed. You can then remove the old certificate from the registration.

Your users stay the same people

A Microsoft account is identified by its directory object id, the id Microsoft Graph returns. That id belongs to the person in their directory, whichever app registration signed them in. So someone who used the Privasys registration before you brought your own keeps their account, and the app keeps seeing the same subject.

This holds for members of your tenant, and for anyone signing in to a multi-tenant registration from their own tenant. One case differs: someone you invited to your tenant as a guest has a separate object in your directory, with its own id. Signing in to a single-tenant registration as that guest is a different account from the one they have under their home tenant. If you already have people on the platform who will come back as guests, tell the app's owner before you switch, so their access can be granted again.

What Privasys ID receives

A single-tenant registration answers for its own directory, so apps receive the address your directory holds as verified. A multi-tenant registration cannot, since another tenant's administrator can set any address, so apps receive one only when Microsoft's xms_edov claim says its domain is verified; otherwise they ask the person.

Your staff authenticate with you. Privasys ID receives their directory id, name and email from Microsoft Graph to complete the sign-in, passes what the app has registered as required in the sign-in token, and keeps none of it: the identity provider stores no user profile.