Topic 6 of 6
Identity concepts
Before talking about Microsoft Entra, you need the vocabulary down: authentication, authorization, identity providers, tokens, directories, and federation. The exam asks about these concepts without naming products, so it pays to understand how they work under the hood.
Contents
Authentication and authorization
Authentication (AuthN)
Proving you are who you say you are. It answers who are you? It uses credentials based on three factors:
- Something you know: password, PIN
- Something you have: phone, security key, smart card
- Something you are: fingerprint, face
Authorization (AuthZ)
Deciding what an already authenticated identity can do. It answers what can you do? It's based on roles, permissions (read, write, delete), and attributes (department, location).
Key principle: least privilege, only the access needed for the job.
Always in this order
Authentication first, then authorization. Like a hotel: you show your ID at the front desk (authentication) and get a card that opens your room and the gym, but not other rooms (authorization).
Using a single factor is single-factor authentication; multifactor authentication (MFA) requires two or more factors from different categories. A password plus a PIN isn't MFA: both are something you know.
Identity as the security perimeter
Firewalls and VPN gateways used to mark a network perimeter, and everything inside was trusted. That worked when everyone was in one office, with apps on local servers and company devices. Today that perimeter has eroded because of:
Cloud and SaaS apps
Email, collaboration, and business apps run outside the corporate network.
Remote and hybrid work
Traffic from home or public Wi-Fi may never pass through the perimeter.
Personal devices (BYOD)
Phones and laptops the organization doesn't fully control.
Partner and customer access
External users who need specific resources without joining the internal network.
IoT devices
Connected equipment with credentials and interfaces that are hard to manage.
An attacker who compromises a VPN credential or a cloud account bypasses the perimeter entirely. An identity is the set of attributes that define a person, device, or software component: for a user, their username, role, permissions, and authentication methods; for a device, its hardware ID, enrollment, and compliance.
The question is no longer "does this come from our network?" but "who or what is making the request, and should we trust it?". That's why identity is the new security perimeter: every access decision starts with it.
Identity types
👤 Human
Employees, contractors, customers, and partners who sign in to applications and data.
💻 Devices
Laptops, phones, tablets, and IoT sensors. They can be enrolled in management, checked for compliance, and trusted or restricted based on their state.
⚙️ Workload identities
Apps, services, containers, and automated processes that access APIs, databases, and other resources without a person involved.
🤖 AI agents
Assistive or autonomous agents that act for users or processes. They need identities built for them, beyond application identities, to authenticate, authorize, and govern their lifecycle at scale.
All four must be authenticated and authorized: a compromised application credential gives the same access as a compromised user account, and an ungoverned agent brings the same risks.
The 4 pillars of an identity infrastructure
Managing identities means covering their whole lifecycle, not just sign-in:
Administration
Creating, assigning, updating, and deleting identities (provisioning when someone joins, deprovisioning when they leave) and defining the policies to manage them.
Authentication
Verifying that the identity is who it claims to be by requesting sufficient legitimate credentials before granting access.
Authorization
Deciding what the authenticated identity can do by evaluating its permissions and the request's context.
Auditing
Recording who did what, when, and from where: sign-in logs, reports, alerts, and forensics. Key for compliance and incident investigation.
The identity provider
With modern authentication, authentication and authorization are provided by a dedicated central service: the identity provider (IdP). It creates and maintains identity information and offers authentication, authorization, and auditing services to applications.
The user opens the application
The app doesn't handle passwords: it redirects them to the IdP.
The IdP verifies the credentials
It applies its policies, for example MFA.
The IdP issues a security token
The client presents it back to the application.
The app accepts the token
It trusts the IdP and uses the token's information to grant access.
Without a central IdP
- Fragmented credentials: one password per app, reused and weak
- Inconsistent password and MFA policies
- Admin overhead: changing access app by app; forgotten accounts
With a central IdP
- The same authentication policies, including MFA, for every app
- Sign-in monitoring across the whole environment
- Full lifecycle: provisioning on join, deprovisioning on leave
Tokens, claims, and protocols
A security token is a structured package of data issued by the IdP. It carries claims: pieces of information about the identity, such as its unique identifier, name and email, roles or groups, when it was issued and when it expires, and what it grants permission to do.
ID token
Proof that the user signed in (authentication). The app uses it to know who they are: name, email, identifier.
Access token
Permission for the app to access a specific resource on the user's behalf (authorization), like reading the calendar or calling an API.
Tokens expire so a stolen one doesn't work forever, and the server validates them through its trust relationship with the IdP.
| Protocol | Used for |
|---|---|
| OpenID Connect (OIDC) | Authentication in modern cloud and mobile apps: verifying who the user is and getting their basic profile. Built on OAuth 2.0 |
| OAuth 2.0 | Authorization: getting access tokens to reach protected resources on the user's behalf |
| SAML | Enterprise scenarios, integrating older apps, and federation between organizations; common with on-premises identity |
Single sign-on (SSO)
With SSO you sign in once to the IdP and are automatically signed in to every app that trusts it, without retyping credentials. It works because each app validates the token against its trust relationship with the same IdP.
Better experience
No need to remember one password per application.
Stronger security
Fewer credential prompts: fewer chances for phishing and less reuse.
Central control
Disabling the account in the IdP removes access to every app immediately.
Microsoft Entra ID is a cloud IdP with SSO for thousands of applications; Google, Amazon, LinkedIn, and GitHub are too. SSO happens within one IdP; when two different IdPs trust each other, that's federation.
Directory services and Active Directory
A directory stores information about users, devices, groups, policies, and applications; the directory service makes it available. Microsoft's Active Directory Domain Services (AD DS) is the most widely used on on-premises networks: a server running AD DS is a domain controller.
AD DS provides
- A single identity per user across on-premises systems
- Group Policy to configure computers
- Authentication with Kerberos and NTLM
- Organizational units (OUs)
Limits in a modern environment
- Doesn't natively authenticate cloud and SaaS apps
- Doesn't manage iOS or Android without extra solutions
- Doesn't natively support OAuth 2.0 or OpenID Connect
- Requires a VPN outside the office
Microsoft Entra ID is the cloud evolution: identity as a service (IDaaS), with modern, cross-platform authentication and no VPN. Connected to AD DS, it forms a hybrid identity.
Federation
Federation grants access across organizations or domains through trust relationships between identity providers. It's like a passport: your country issues it and others accept it without giving you new ID. The user signs in with credentials they already have and needs no new account in the other organization.
Organization A configures its IdP to trust B's IdP
It's an explicit decision by A.
A user from B tries to access a resource in A
They authenticate with their own IdP (B's).
A's IdP accepts that authentication
And grants access based on the trust relationship.
Trust isn't bidirectional by default
If organization A trusts B, B doesn't automatically trust A. Two-way trust is configured explicitly.
B2B collaboration
A partner's employees access shared resources with their company credentials, without you creating and managing guest accounts one by one.
Social providers
Signing in to an app with your Google, Microsoft, or GitHub account. It reduces sign-up friction in customer apps.
AD FS
Active Directory Federation Services: on-premises AD users access cloud apps by authenticating against an AD FS server that issues tokens the cloud accepts.
Exam scenarios
| Situation | Concept | Why |
|---|---|---|
| The user types their password and approves a phone notification | Multifactor authentication | It combines something you know with something you have. |
| An authenticated user can read but not delete a file | Authorization | It decides what an already verified identity can do. |
| An app gets permission to read the user's calendar | Access token (OAuth 2.0) | It authorizes access to a resource on the user's behalf. |
| An app needs to know who signed in | ID token (OpenID Connect) | It proves authentication and identifies the user. |
| Disabling an account removes the employee's access to every app | SSO with a central IdP | Every app trusts the same identity provider. |
| A partner's employees sign in with their company credentials | Federation (B2B) | A trust relationship between two identity providers. |
| On-premises AD users access cloud apps through a local server | AD FS | Federation of on-premises identity to cloud services. |
Common exam traps
❓ Which protocol is used to authorize access to a resource on the user's behalf?
OAuth 2.0. OpenID Connect is built on OAuth 2.0 for authentication.
❓ If A trusts B, does B trust A?
Not necessarily. Federation isn't bidirectional by default.
❓ Which of the 4 pillars records who did what and when?
Auditing. Administration handles the identity lifecycle.
❓ Is a password plus a PIN MFA?
No. Both are "something you know". MFA requires factors from different categories.
❓ Which token does an app use to know who the user is?
The ID token. The access token is for accessing resources on their behalf.
❓ Are SSO and federation the same thing?
No. SSO is signing in once to one IdP for many apps; federation is trust between two different IdPs.
❓ Does AD DS natively support OpenID Connect?
No. AD DS uses Kerberos and NTLM; Microsoft Entra ID provides modern authentication.
Did you get this topic?
Test what you just learned
A user signs in once and then accesses email, the CRM, and the intranet without retyping credentials, because they all trust the same identity provider. What capability does this describe?
Ready to test "Identity concepts"?
Original questions, each with a full explanation.
Start a mock exam