Microsoft Entra ID as a login source in authentik for a self-hosted identity layer
Consider a team that runs authentik on its own infrastructure and wants staff to sign in with the Microsoft Entra ID accounts they already use. The supported method is an Entra ID OAuth source, which sends users to Microsoft for sign-in and returns them to authentik with an identity. Whether to also provision Entra users and groups into authentik over SCIM is a separate decision that depends on where the directory of record should live, so it should be made on its own rather than assumed as part of the login setup. Before scoping anything, confirm the edition. The authentik pricing page lists Google Workspace and Microsoft Entra ID integrations among its enterprise-only features, so a team on the Open Source edition should not plan around this source until the licensing question is settled with authentik.
The licensing check matters for more than the sign-in button. authentik's repository is mostly MIT-licensed, but code under the authentik/enterprise/ directory is covered by a separate enterprise license, and the pricing page lists per-user fees for the Enterprise edition. Ask for the current fee schedule, billing terms and what the subscription covers for external users, because those figures determine the recurring cost of this design. Also confirm which authentik release line you will run, since the security policy lists 2026.5.x and 2026.8.x as supported lines receiving security fixes. DeployOpen implements this integration inside your own cloud accounts, data centers or private network, so the Entra app registration, redirect URIs, client secret handling and authentik configuration all stay under your control, and the written scope should name each of those items.
What you need before connecting Entra ID to authentik
Connecting Entra ID to authentik touches four areas: the authentik release you run, the edition that includes the integration, the Microsoft side where an admin registers the application, and the network and certificate path between users, authentik and Microsoft. Confirm each one before you open a change window, because several of them are hard to change later.
Supported authentik release line
Run a release from a line that still receives security fixes. The authentik security policy lists 2026.5.x and 2026.8.x as supported, and the project announces security releases at least 24 hours in advance. Check which minor version you are on, plan the upgrade path first if you are on an older line, and confirm the exact patch level you will deploy against the current release list.
Enterprise edition for the Entra integration
The Microsoft Entra ID integration is listed as an Enterprise-only feature on the authentik pricing page, not in the Open Source edition. Ask your authentik contact to confirm that the Entra ID provider and SCIM capabilities you need are included in the subscription you buy, and get the license terms in writing before you design around them. The code under the enterprise directory is covered by a separate license.
Tenant admin rights for app registration
Someone with rights to register applications and grant admin consent in the Microsoft Entra tenant must create the app registration, record the client ID and secret, and configure the redirect URI. Confirm that person before the project starts, and agree on who owns the client secret and its rotation schedule, since an expired secret stops sign-in without a clear error on the authentik side.
Entra ID licensing tier
Entra ID Free covers basic single sign-on, while group-based access and some provisioning scenarios depend on the tier you hold. Microsoft lists Entra ID P1 from $7.00 per user per month and P2 from $10.00 per user per month with annual commitment, and P1 is included in Microsoft 365 E3 and Business Premium. Check your current tier in the admin center, and confirm with Microsoft which features your group claims and provisioning design requires.
Tenant data location
An Entra ID tenant's data location is set from the country or region chosen at tenant creation and cannot be changed afterward. Multifactor authentication data is stored in North America and or the tenant's geo-location. Record the tenant location and the cloud instance, including whether you use a US government or China cloud, because your data residency commitments and any authentik data handling statements must match it.
Network path and callback certificate
Users need outbound access to Microsoft sign-in endpoints, and the authentik server needs outbound access to Microsoft token and Graph endpoints during sign-in and any sync. Browsers must reach the authentik callback URL over HTTPS through your reverse proxy, which needs a valid certificate chain that Microsoft and browsers trust. Test each path from the authentik host, not only from your workstation, and document any egress proxy rules.
Configure the Entra ID source in authentik step by step
This sequence connects a Microsoft Entra ID tenant to authentik as an OAuth source so pilot users can sign in with their work accounts. It finishes with a tested login path, and you can widen access once enrollment and account linking behave as intended.
Confirm the license and tenant details
Before any configuration, confirm that your authentik edition includes the Microsoft Entra ID integration, which the authentik pricing page lists as an Enterprise feature. Ask your Entra administrator which tenant will be used and confirm its data location, because that is set when the tenant is created and cannot be changed later. Agree on a small pilot group of test accounts. This step is complete when the license question is answered in writing and the tenant owner has approved the pilot.
Start the source and note its redirect URI
In the authentik admin interface, open the federation and social login section under Directory and start a new Microsoft Entra ID source. Give it a clear name and slug, because both appear in login URLs. Copy the redirect URI that the source form displays. If your authentik version requires client credentials before the source can be saved, confirm that behavior in the release you run and keep the form open until the credentials exist. This step is complete when you have the exact redirect URI in hand.
Register the application in Entra ID
An Entra administrator opens the Microsoft Entra admin center, goes to App registrations, and selects New registration. Enter a name the pilot team will recognize, choose the account types that match your tenant policy, and select the Web platform. Paste the redirect URI copied from authentik exactly, including the trailing characters, since a mismatch causes the sign-in to fail. This step is complete when the application appears in the App registrations list and its overview page shows the expected redirect URI.
Create the client secret and record the IDs
In the new application, the administrator opens Certificates and secrets and creates a client secret. Copy the secret value at once, because Entra does not show it again after you leave the page. From the application overview, record the Application (client) ID and the Directory (tenant) ID. Store the secret in your approved secrets store, not in a ticket or chat. This step is complete when the client ID, tenant ID and secret value are recorded in a location the authentik administrator can reach.
Enter credentials and set enrollment and linking
Return to the authentik source form and enter the tenant ID, client ID and client secret. Next, decide how the source treats people who do not yet have an authentik account. Enrollment controls whether a first-time Entra user can create an account automatically. Linking controls whether a sign-in can attach to an existing authentik user, usually by matching a stable attribute such as email. Choose matching fields that your Entra tenant keeps unique, and confirm the matching options in your authentik version before the pilot. This step is complete when the source is saved and its button appears on the authentik login page.
Test sign-in with a pilot account
Sign in from a private browser session using a pilot Entra account, and select the new source button on the authentik login page. Approve any consent prompt Entra shows. Then open the user list in the authentik admin interface and confirm that either one new user was created or the pilot user linked to the existing account, with no duplicate. Check that the email and name attributes match Entra. Keep a local administrator session open throughout, so a misconfigured source cannot lock out your team. This step is complete when a pilot user signs in successfully and the resulting user record matches expectations.
When to keep Entra ID as the master directory
The first decision is whether authentik only needs Entra ID for sign-in, or whether it should also mirror Entra users and groups. With an OAuth source alone, authentik redirects users to Entra ID, accepts the identity it gets back, and creates or links a local account on first login. Entra remains the place where accounts are created, disabled and protected by its own sign-in policies, and authentik holds only what it needs to authorize applications. With inbound SCIM provisioning, authentik instead receives a copy of users and groups and keeps that copy current. That mirror is what you want when authentik policies, application access or group-based permissions must depend on Entra group membership that is not present in a login token. Confirm which of these two models your applications actually need before you build either one.
Whichever path you choose, decide who owns the user lifecycle before the first sync runs. If Entra is the master directory, joiners, movers and leavers are handled there, and authentik should treat its copy as read-only so that local edits do not drift from the source. If the authoritative record for some attributes lives in an HR system or in on-premises Active Directory, Entra may itself be a downstream copy, and authentik would then be two steps removed from the truth. For hybrid estates, Microsoft's Microsoft Entra Connect and Connect Health documentation describes Entra Connect as the on-premises application that synchronizes Active Directory users, groups and password hashes, and describes Entra Cloud Sync as the future direction. Confirm with your Microsoft administrators which tool is in use, because authentik's configuration must match what Entra actually holds.
Plan for licensing and operations as well. Entra Connect is free with an Azure subscription, but Entra Connect Health requires Entra ID P1 licenses, so budget for that if you rely on its monitoring for the sync path. Ask who will watch the sync: a failed or stalled provisioning job leaves authentik with stale group memberships, which can grant or withhold access without anyone noticing. Document the authoritative attribute for each field you import, such as userPrincipalName or the on-premises identifier, and agree on how the SCIM correlation key maps to the local user, because a wrong key creates duplicate accounts. Treat a sign-in-only deployment as the simpler default, and move to full sync only when a concrete access decision requires Entra group data inside authentik.
Login only, inbound SCIM or both: choosing the integration shape
Login only uses the OAuth source so Microsoft Entra ID checks the password, MFA and sign-in policies, and authentik receives a signed identity for each sign-in. authentik still creates and stores its own user record, and its group membership comes from claims received at sign-in or from groups you assign locally. This shape changes the least in your directory and is the easiest to reverse.
- Password ownership: Entra ID holds the credential and its policies, so authentik never sets or resets the password.
- Group membership: Groups are only as current as the claims received at the last sign-in, so each local application role needs a named owner.
- Deprovisioning: A disabled Entra account stops new sign-ins, but the authentik user and any open sessions remain until you disable them or the session ends. Confirm the timing in your own tenant.
- Edition requirements: The authentik pricing page lists the Microsoft Entra ID integration as an Enterprise feature, so confirm the edition you need with authentik before you plan around it.
Confirm which group claims your app registration emits and whether your tenant sends group identifiers or names before you map anything.
Inbound SCIM makes Entra ID the system of record. Users and groups are created, updated and removed in authentik from provisioning events sent by Entra ID, so authentik consumes directory data instead of maintaining its own. Applications still trust authentik for sign-in, but who exists and who belongs to which group is decided in Entra ID. Manual edits to provisioned objects in authentik are likely to be overwritten on the next sync, so treat them as read-only.
- Password ownership: Entra ID remains the only place passwords are set. Sign-in for these users is delegated to Entra ID, so authentik does not need to hold a local password for them.
- Group membership: Application access should be assigned through Entra ID groups that provision into authentik, not through groups edited in authentik.
- Deprovisioning: Disabling or unassigning a user in Entra ID is the main offboarding control. Confirm how deletes and deactivations are handled and how quickly changes arrive.
- Existing local objects: Users and groups created in authentik before provisioning starts need a correlation plan so they are not duplicated or orphaned.
Confirm the provisioning scope, the attribute mapping and what happens to objects that exist only in authentik before you turn provisioning on.
The hybrid shape lets Entra ID sign users in while authentik keeps its own groups for application authorization, such as admin roles in a self-hosted tool that exists only in your environment. Identity comes from Entra ID, and authorization is split. Entra ID groups give coarse membership, and authentik groups carry application-specific decisions. This shape is the most flexible and needs the clearest ownership rules.
- Password ownership: Entra ID holds passwords for directory users. authentik holds only the local accounts you create for specific purposes, such as service or break-glass access, and those should be documented separately.
- Group membership: Map selected Entra ID groups to authentik groups, and record which side wins when both change.
- Deprovisioning: Offboarding needs two checks: the Entra ID account is disabled, and the authentik groups or local accounts that Entra ID does not manage are cleared.
- Break-glass access: Keep at least one local administrator path that works when Entra ID is unavailable, and test it on a schedule your team sets.
For each group, confirm whether Entra ID or authentik owns it, and get that answer signed off by the team that approves access.
Choose the shape by asking where access decisions should be made and recorded. If your access reviews already run in Entra ID, login only or inbound SCIM keeps one record of truth. If application teams manage roles inside each tool, the hybrid shape may fit better. The answer also depends on how your tenant is licensed and synchronized, so check those facts before you commit.
- Directory ownership: Identify the system that your HR and access review processes update. That system should own the group that grants access.
- Existing synchronization: Find out whether Active Directory already feeds Entra ID through Microsoft Entra Connect or Cloud Sync, since that changes where user attributes originate.
- Licensing: Microsoft lists Entra ID P1 and P2 as separate per-user tiers, so confirm which tier your tenant holds and which features it includes.
- Application count: Each application that reads groups adds mapping work, so fewer shared groups usually means less drift.
- Audit trail: Decide which system will be the source for access evidence and confirm that its logs cover the changes you need to show.
Write the chosen shape into a one-page decision record and have your identity owner and application owners confirm it before the app registration is created.
Mapping Entra ID attributes and group claims to authentik
This table compares each Entra ID attribute or group signal with the authentik field it should populate and the stability rules that matter for correlation. Read it before building the source so the identifier you match on never changes after the first sync. The main takeaway is that the object ID and the on-premises identifiers are the safer anchors, while email-style names are easier to change.
| Entra ID source | Suggested authentik target | Stability and team check |
|---|---|---|
| userPrincipalName | Username (unique identifier) | Can change when a user is renamed or domains change. Confirm whether your naming policy allows changes before using it as the sole match key. |
| Email attribute | Often differs from the UPN and may be empty for some accounts. Confirm which address your applications expect in the email claim. | |
| displayName | Name attribute | Free text that users or admins edit. Safe for display, not for matching or access decisions. |
| department | Custom attribute on the user | Useful for policy or group rules, but reflects HR data quality. Confirm the source of truth before writing rules against it. |
| onPremisesSamAccountName or onPremisesImmutableId | Custom attribute for hybrid correlation | Present only for directory-synced accounts. Stable across renames in most hybrid setups. Confirm the attribute Entra Connect or Cloud Sync populates in your tenant. |
| Object ID (id) | External ID or stored correlation key | Stable for the life of the account in Entra ID. Recommended as the key that links records across renames and migrations. Confirm it is retained in the source mapping. |
| Group membership or group claims | authentik group membership used by policies | Confirm in the app registration whether groups are emitted as object IDs or names, and whether overage limits apply for users in many groups. |
| Group object IDs versus display names | Group name in authentik | Display names can be renamed in Entra ID, so match on object ID and store the name as a label only. |
Hardening the Entra ID connection
An Entra ID source gives authentik a trust path into your workforce directory, so the connection itself needs the same care as the directory. The cards below cover the credentials, tenant boundary, MFA enforcement, SCIM token, app permissions and audit trail that you can check after go-live.
Protect and rotate the client secret
The OAuth source and the app registration depend on a client secret that lets authentik request tokens on behalf of the application. Store the secret in your secrets manager rather than in exported configuration files, restrict who can read it in the authentik admin interface, and record its expiry date in your change calendar. Rotate it before expiry, then confirm sign-in works with the new value before you remove the old one. Ask your team who holds the Entra admin role that can generate a new secret.
Restrict sign-in to your tenant
A multi-tenant app registration can accept accounts from other Entra tenants, which matters if the source is configured for a common or organizations endpoint. Pin the source to your own tenant ID so only your directory's users can start a login. Check the issuer and tenant claims in a test sign-in, and confirm that a user from a different tenant is refused. Recheck this setting whenever someone edits the app registration's supported account types.
Enforce MFA with Conditional Access
authentik does not know whether Entra asked a user for a second factor unless your Entra policy enforces it. Create a Conditional Access policy that targets the app registration and requires MFA, then test a sign-in from an unmanaged device. Review the authentication methods that Entra accepts, and decide whether authentik's own MFA stages should add a second check on top. Do not assume MFA is in place because the sign-in works.
Limit the SCIM provisioning token
The inbound SCIM token can create, change and disable users and groups, so it is a high-trust credential. Generate it only for the Entra provisioning connection, scope the app role assignments to the groups that should flow into authentik, and store the token outside chat tools and tickets. Plan a rotation date and a test that confirms a deprovisioned user loses access. Keep the token's owner and its purpose recorded so that a later reviewer can tell why it exists.
Grant least-privilege app permissions
Request only the Microsoft Graph permissions the sign-in and sync need, and grant admin consent after you read each one. Avoid broad directory-write permissions for a read-oriented login flow. Record which permission supports which function, so that a later change is reviewed against the sign-in or provisioning need it serves. Ask your Entra administrator to confirm the consent record in the enterprise application view.
Use enhanced audit logging
Enhanced audit logging is listed as an Enterprise-only feature on the authentik pricing page, so confirm its availability before you plan your evidence collection around it. Whichever edition you run, send authentik's authentication and provisioning events to your log platform and keep Entra sign-in logs in the tenant. Test that a failed login and a deprovisioning event both appear in both places. Ask your vendor which events each edition records.
Common Entra ID source failures and fixes
This table pairs each common failure when Entra ID is connected to authentik with its likely cause and the first check to run. Read it top to bottom during setup or when sign-in breaks, starting with the symptom your users report. The main takeaway is that most failures trace back to a mismatch between the app registration, the authentik source settings and the identity correlation plan, so check those three before changing anything else.
| Symptom | Likely cause | First check |
|---|---|---|
| Redirect URI mismatch error after Entra sign-in | The redirect URI registered on the Entra app registration does not match the callback URL authentik generates for the source, often because the slug or domain differs. | Compare the redirect URI in the Entra app registration character by character with the callback shown on the authentik OAuth source, including scheme, host and trailing slash. |
| Invalid tenant or issuer errors on the login page | The tenant ID or OpenID configuration endpoint in the source points to a different tenant, or uses the wrong endpoint for your Entra cloud. | Open the OpenID configuration URL built from your tenant ID in a browser and confirm the issuer matches the value authentik expects. |
| Users created as duplicate accounts | Correlation was not planned, so a user who already exists locally or from LDAP or SCIM was matched on a different identifier than the one Entra sends. | Check which attribute authentik uses to link the source user to an existing account and confirm that attribute is populated and identical in both directories. |
| Group membership missing after sign-in | The app registration does not emit group claims, or the group claim type does not match the property mapping in authentik, or groups are assigned by nested membership that the token omits. | Decode a test token or inspect the claims returned for a test user, then confirm the group claim type and the mapping in the source. |
| Groups show as object IDs instead of names | Group claims were sent as GUIDs, so authentik matches on IDs that differ from the group names administrators expect. | Confirm which group identifier the claim carries and align group matching or the mapping with the identifier your policies use. |
| SCIM token rejected by the Entra provisioning connector | The bearer token was regenerated, expired, copied with extra whitespace, or issued by a different authentik source than the one the connector targets. | Test the SCIM base URL and token with a simple read request, then confirm the token belongs to the SCIM source the connector uses. |
| Users cannot sign in after an authentik upgrade | The new release changed source, flow or policy behavior, or the upgrade skipped a required intermediate version, so existing bindings no longer match. | Review the release notes for the version you moved to, confirm the upgrade followed the sequential path, and check the source and flow bindings still exist. |
| Entra users disabled or removed unexpectedly after SCIM sync | Entra is the master directory and the deprovisioning scope or attribute mapping removes accounts that authentik treats as managed. | Review the provisioning scope and attribute mappings in Entra, and confirm which system is authoritative for each user attribute before re-enabling sync. |
Questions buyers ask before connecting Entra ID to authentik
Does connecting Entra ID to authentik require the Enterprise edition?
Yes, the Microsoft Entra ID integration is listed as an Enterprise-only feature on the authentik pricing page. The Open Source edition is free and is supported through the community Discord only. Enterprise is listed at $5 per user per month billed annually, plus $0.02 per external user per month, and Enterprise Plus starts at $20k annually. Confirm the current terms with authentik before budgeting, because the edition boundaries and the basis for counting users determine which tier applies to your tenant. The Enterprise license also governs code in the enterprise directory, which is separate from the MIT-licensed core.
What drives the effort of an Entra ID integration?
The effort is driven by four things: the shape of your tenant, how your groups are modeled, how far SCIM provisioning reaches, and how many accounts already exist in authentik. A single tenant with a clear group model and a small set of applications is a narrow job. Multiple tenants, nested or dynamic groups, guest users and external identities add mapping and testing work. SCIM scope matters most: deciding whether authentik only signs users in or also creates, updates and deactivates them changes the test matrix. Existing local accounts need a correlation plan so that a user who signs in with Entra ID is linked to the right record and not duplicated.
Can an internal team connect Entra ID to authentik without outside help?
Yes, a team with administrative access to both the Entra admin center and the authentik instance can build the OAuth source themselves, and the authentik documentation covers the source and provider configuration. The work that tends to be underestimated is the mapping of groups and claims, the SCIM token handling and the failure testing: what happens when a user is disabled in Entra, when a group is removed, or when a sign-in arrives before provisioning has run. Teams that have not run identity federation before often benefit from an external review of the design. DeployOpen can scope that work as a fixed-scope engagement, with deliverables agreed in writing before work starts.
How long does a pilot of the Entra ID integration take?
The duration depends on scope. A pilot that only tests sign-in for a small group of users is much shorter than a pilot that also validates SCIM provisioning, group-based access and offboarding. The main variables are the number of applications that depend on the source, the number of pilot users and their groups, how quickly your Entra administrators can make app registration and group changes, and how many rounds of testing your change process requires. Ask for a timeline tied to a written list of pilot criteria, so the end point is a set of verified behaviors rather than a date.
What does our team need to provide for the integration?
The team needs to provide several things before work starts:
- Administrative access to the Entra admin center sufficient to register the application, configure group claims and, if SCIM is in scope, create the provisioning configuration.
- Administrative access to the authentik instance and the ability to change its configuration in a non-production environment first.
- A named set of pilot users and the groups they belong to, including people who should be denied access.
- Decisions on which directory is the master for users and groups, and which attributes authentik may overwrite.
- Owners for each application that will trust authentik, and a contact who can approve the offboarding rules.
Missing decisions on the master directory are the most common cause of rework, so settle them before configuration begins.
Which Microsoft licenses does the team need for this integration?
The authentik integration itself does not require a specific Entra license, but your tenant's license determines which Entra features are available to your users and admins. Microsoft lists Entra ID Free as included with Azure and Microsoft 365 subscriptions, covering MFA, SSO to SaaS apps, basic reports and self-service password change. Entra ID P1 is listed from $7.00 per user per month and P2 from $10.00 per user per month, both with annual commitment. P1 is included in Microsoft 365 E3 and Business Premium, and P2 in Microsoft 365 E5. Check the Microsoft Entra pricing page for current terms, and confirm with your Microsoft account team which plan your users already hold before you design group-based access.
Should Entra ID stay the master directory when authentik is added?
Keep Entra ID as the master directory when it already holds the authoritative user lifecycle, such as joiner, mover and leaver events driven by HR or on-premises Active Directory synchronization. In that model authentik signs users in and receives their groups, and it should not become a second place where accounts are created by hand. Make authentik the master only if it will own lifecycle decisions and Entra is a consumer. Microsoft Entra Connect is an on-premises application that synchronizes Active Directory users, groups and password hashes to Entra ID, and Microsoft describes Entra Cloud Sync as the future of synchronization, so confirm which sync path your environment already uses before you decide.
What data residency questions should we raise for Entra ID?
Start with the tenant location. An Entra ID tenant's data location is mapped from the country or region chosen at tenant creation and cannot be changed afterward, and Entra multifactor authentication data is stored in North America and or the tenant's geo-location. Entra ID is also offered in US government and China clouds, and in China it is operated through a partnership with 21Vianet. If your regulator or contracts restrict where identity data may be processed, document this before you connect the tenant. Review the Microsoft Entra data residency documentation with your compliance team, since these facts affect the design of the integration.
How DeployOpen scopes and delivers the Entra ID source
DeployOpen treats the Entra ID source as a scoped piece of identity work: which users sign in, which groups map to authentik roles, and whether Entra stays the master directory. The engagement is planned and delivered inside the infrastructure you control, with the written scope fixed before any build begins.
How we scope
- Confirm which Entra tenant, app registration owner and redirect URLs the written scope will cover.
- Record whether Entra stays the master directory or authentik becomes the place where users are managed.
- Agree the group-to-role mapping, enrollment behavior for first sign-in and the users in or out of scope.
How we build
- Configure the OAuth source, claim and group mappings and the app registration in your own tenant.
- Set up the SCIM inbound path only where the scope calls for it, with the token handled as a high-trust secret.
- Test sign-in, group claims, deprovisioning and fallback login with representative accounts before cutover.
How we hand over
- Deliver configuration documentation covering source settings, mappings, tenant prerequisites and known limits.
- Provide a runbook for rotating the client secret, changing group mappings and handling a failed sync.
- Walk your administrators through the setup so your team can operate the source after handover.
How we support
- Engagements are fixed-scope, so changes to the agreed scope are written up and priced before they proceed.
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Ask us to confirm how the retainer covers authentik upgrades and Entra tenant changes you plan.
