Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article explains how Employee Self-Service authenticates with external HR and IT systems, why user-delegated access is the recommended model for employee scenarios, and how to choose between user-delegated and system access patterns.
Important
Your organization owns its authentication and authorization configuration end to end. While Employee Self-Service recommends a user-delegated access model to reduce risk, you're responsible for evaluating your deployment's security posture, applying controls that align with your organizational policies, and mitigating any risks associated with your chosen access patterns.
Overview
When an integration authenticates with a shared system credential instead of the employee's own identity, a single compromised credential can expose every record that account's role can reach, turning a localized issue into an enterprise-wide incident. Employee Self-Service avoids this outcome by design: every request to an external system carries the employee's own delegated credentials.
Employee Self-Service authenticates using the OAuth 2.0 authorization code flow. The employee signs in through Microsoft Entra, and the resulting access token carries only the scopes the employee consented to. Employee Self-Service doesn't cache or elevate tokens beyond that consent grant. This flow gives the external system a real user identity on every call, so its native role-based access control enforces authorization the same way it would for any direct user sign-in.
User-delegated calls also inherit Conditional Access policies, MFA challenges, sign-in risk evaluations, and session controls from the employee's Microsoft 365 sign-in. Not leverging on-behalf-of (OBO) authentication bypass all of these policies by design: once the credential is provisioned, every call is implicitly trusted regardless of device posture, location, or risk signal.
Who needs to be involved
- HR system admin (Workday or ServiceNow): registers the OAuth client and configures user-facing security policies in the external system
- M365 tenant admin: approves the app registration and consent grant in Microsoft Entra
- Identity admin: verifies that Conditional Access policies, MFA requirements, and user consent settings align with organizational security policy
For system-specific setup steps, see the connector documentation linked in Related content.
How Employee Self-Service authenticates
Scope verification
Employee Self-Service doesn't request broad administrative scopes. The OAuth scope set is limited to what the employee's role requires. Customers can verify the exact scopes granted to the Employee Self-Service application through the enterprise applications consent view in Microsoft Entra.
Audit trail
Every action is tied to the employee's real identity. The following table shows where audit records appear:
| Event type | System that records it | What to look for |
|---|---|---|
| Data read/write on behalf of the employee | External system (Workday audit trail, ServiceNow sys_audit / transaction log) | Action attributed to the employee's external-system identity |
| Authentication and token issuance | Microsoft Entra sign-in logs | Sign-in event, Conditional Access evaluation result, MFA status |
| Consent grant or revocation | Microsoft Entra audit logs | Application consent events for the Employee Self-Service app registration |
Consult your external system's audit log documentation for retention policies and access controls. Microsoft Entra sign-in logs are retained for 30 days by default (up to 365 days with Microsoft Entra ID P1/P2).
When to use each access pattern
Warning
Using a system account for employee actions is a form of privileged access and is a well-established anti-pattern for user-facing scenarios. A compromised credential exposes every record its role can reach. Even when privileged access is necessary, it should follow rigorous controls: time-bounded sessions, just-in-time provisioning, and continuous monitoring. For employee-facing operations, user-delegated access avoids the need for these controls entirely.
User-delegated access for employee-facing scenarios
Employee Self-Service doesn't recommend system-account authentication for employee-facing scenarios. User-delegated access is the recommended model for all employee interactions, including self-service HR and IT workflows, personal data access, and any action that requires traceability.
Workday examples
| Scenario | Recommended access |
|---|---|
| View payslip | User-delegated |
| Update personal details | User-delegated |
| Submit leave request | User-delegated |
| View time-off balance | User-delegated |
| Request time off | User-delegated |
| View benefits elections | User-delegated |
| Update emergency contacts | User-delegated |
| View compensation details | User-delegated |
ServiceNow examples
| Scenario | Recommended access |
|---|---|
| Create or update tickets | User-delegated |
| View personal requests | User-delegated |
| Interact with HR or IT workflows | User-delegated |
| Check ticket status | User-delegated |
| Add comments or attachments to a case | User-delegated |
| View knowledge articles (user-scoped) | User-delegated |
| Submit onboarding or offboarding requests | User-delegated |
System-level access for non-employee-specific operations
Non-OBO accounts are appropriate for read-only, non-employee-specific operations:
- Synchronizing organizational data (org charts, cost centers)
- Fetching catalog or reference data (service catalogs, knowledge articles)
- Running scheduled backend jobs (data reconciliation, provisioning)
These operations are typically ingestion scenarios where the consuming service applies its own role-based access control (RBAC) layer on top of the imported data, providing another security boundary beyond the source system's access controls.
These identities remain useful when applied intentionally to the scenarios in this section. They aren't recommended as an alternative for employee-facing operations.
What can go wrong with system accounts in employee scenarios
The following scenarios illustrate the risks when system-account authentication is used for employee-facing operations:
Credential theft leading to mass data exfiltration: An attacker obtains a non-OBO credential through a configuration leak, a phishing attack against an admin, or a compromised CI/CD pipeline. Because that credential has access to all employee records, the attacker can exfiltrate payslips, compensation data, and personal information across the entire organization. With user-delegated access, the same attack vector yields only one employee's data and Conditional Access policies can block the session entirely based on device posture or sign-in risk.
Insider threat with unattributable impersonation: A malicious insider with access to an account can submit HR requests such as time-off changes, personal information updates, benefit elections as any employee. Without OBO, audit logs do not record which user made the actions, making forensic investigation harder. User-delegated access ties every action to the employee's real Microsoft Entra identity, preserving attribution.
Compromised integration enabling lateral movement: An attacker compromises a non-OBO account. Under that account's broad role, they can create and modify tickets, access HR cases across the organization, and potentially escalate privileges. User-delegated scoping limits each session to the data and operations that one employee is authorized for, containing the blast radius.
Summary
Employee Self-Service recommends authenticating as the employee on every call to an external system. This configuration ensures that the external system's native access control enforces authorization, audit logs reflect the real user, and Conditional Access policies apply to every session.