By default, signing in with Microsoft means consenting to the Kolleno application, which we own and maintain. Clients whose Kolleno instance runs on dedicated infrastructure can instead supply an Entra app registration created in their own tenant, so the credential and the sign-in policy belong to their IT team rather than to us.

This option is available to clients with a dedicated Kolleno deployment, which has its own hostname (for example app.yourcompany.kolleno.com) and its own database.

It is not available on the shared Kolleno platform. There, a single Kolleno app registration serves every customer, and the sign-in flow has no way to tell which company a person belongs to until after they have authenticated with Microsoft, which is too late to choose a different registration. If you are unsure which applies to you, ask your Kolleno contact.

Both options give you an application in your own tenant, so Conditional Access, group assignment and sign-in logs work the same way either way. The difference is ownership of the credential.

Register the application with the Web platform. This is the single most common setup mistake: a Single-page application (SPA) registration is treated by Entra as a public client, and it will reject the credential when Kolleno exchanges the sign-in code for a token. The failure happens after a seemingly successful sign-in, which makes it confusing to diagnose.

Add one redirect URI, under that Web platform:

https://<your Kolleno API hostname>/auth/microsoft/redirect/

Your Kolleno contact will confirm the exact hostname. Enter it exactly as given, including the trailing slash. A mismatch produces error AADSTS50011 at sign-in.

Single tenant (Accounts in this organizational directory only) is the right choice and the one we recommend. Tell us your Directory (tenant) ID so we can point Kolleno at your tenant directly.

This matters more than it looks. A single-tenant registration cannot be reached through Microsoft's shared /common sign-in endpoint, and attempting it fails with AADSTS50194. Giving us the tenant ID avoids that, and it is also what makes sign-in work for guest (B2B) accounts in your directory, which would otherwise be sent to their home tenant instead of yours.

Only the standard OpenID Connect sign-in scopes are needed. In the Entra portal these appear under API permissions → Microsoft Graph → Delegated permissions, which is a common source of confusion: they are sign-in scopes, not access to Graph data.

If user consent is disabled in your tenant, an Entra administrator needs to grant admin consent for these. The default User.Read permission that Entra adds to a new registration is not used by Kolleno, and you can leave it or remove it.

Kolleno authenticates to your registration with either a client secret or a certificate.

We recommend a certificate, and most security teams require one.

With a certificate, nothing confidential is exchanged in either direction:

We include the certificate's SHA-1 thumbprint in the message. Please check it against what Entra displays after the upload, which confirms the file arrived intact.

With a client secret, the reverse is true: you generate the secret and have to transmit a live credential to us, which is why certificates are preferred.

A certificate has a fixed lifetime, and when it lapses every sign-in to your Kolleno instance fails. Where SSO is enforced there is no password fallback, so this is a full outage rather than a degraded service. Please record the expiry date and plan the renewal in advance.

Renewal itself is seamless. Entra accepts more than one certificate on a registration, so we issue the replacement and you upload it alongside the current one before we switch across. Let us know if your tenant caps certificate lifetimes, as some do at twelve months, so we issue one that your policy will accept.

Kolleno reads the ID token that Microsoft returns and nothing else. We do not call Microsoft Graph, and we do not retain the Microsoft access or refresh token.

The email claim must be present. Kolleno identifies people by email address and does not fall back to any other claim, so a user whose directory record has no email address will not be able to sign in. If your accounts do not carry one, add email as an optional claim on the ID token under Token configuration.

Because the registration is yours, the usual Entra controls apply and Kolleno does not bypass any of them. Sign-in is an ordinary interactive redirect to Microsoft, so MFA, device compliance, named locations and any other Conditional Access policy are evaluated on Microsoft's login page before Kolleno is given anything.

You can also restrict sign-in to a group by setting Assignment required to Yes on the enterprise application and assigning that group. Note that group-based assignment requires an Entra ID P1 or P2 licence, while assigning individual users does not.

Two things are worth knowing about how this interacts with Kolleno:

Sign-in does not require, and Kolleno does not ask for, any of the following:

Those belong to the optional Microsoft email and inbox integrations, which are a separate connection set up independently of SSO.

We then send you the public certificate to upload, and confirm when the configuration is live on your instance.

Please tell us before deleting or recreating the registration. A new registration means a new Application (client) ID, and the certificate has to be uploaded to it as well, so sign-in stops working until both are in place on our side. The existing certificate can be reused on the new registration, so nothing needs reissuing.