Identity

The Microsoft Identity platform helps you to build apps that your users can sign in to using their Microsoft identities or social accounts, and provide authorised access to your APIs or Microsoft APIs like Graph.

MS ID offers modern features without implementation headachei:

• Passwordless auth
• Step-up auth
• Conditional access

There are several components involved in the Microsoft Identity platform:

• OAuth 2.0 and OIDC compliant auth services
  • Work or school accounts (Entra)
  • Personal Microsoft account (Skype, Xbox, Outlook)
  • Social or local account (Azure AD B2C, Entra External ID)
• Open-source libraries
  MSAL or other standards-compliant library
• Identity endpoint
  Works with MSAL (or other compliant library) and provides human-readable scopes
• App management portal
  Azure portal registration and configuration
• App configuration API
  Scripting configuration through Graph and PowerShell

Application objects and service principals

To delegate identity and access management functions to Microsoft Entra, you need to register an application with a Microsoft Entra tenant.

When you register an application with Microsoft Entra, you can decide whether it is:

• Single tenant
  Has a single application object and service principal in the home tenant.
• Multi-tenant
  Has a single application object but many service principals, one in each tenant.

On creation, an application object and a service principal are created in your "home" tenant. The application object in the home tenant is used as a blueprint to create a service principal in every tenant where this application is used.

The application object describes:

• How the service can issue tokens to access the application
• Resources that the application needs might need to access
• The actions that the application can take

Security principals represent entities that are requesting access to a resource secured by a Microsoft Entra tenant. User principals represent individual users, service principals represent applications. There are three kinds of service principal:

• Application
  A service principal that is an "instance" of the global application object. Exists in all tenants who use the base resource.
• Managed identity
  A special kind of service principal to allow applications to access resources without manual token management (Microsoft does it!).
• Legacy
  For apps crated before app registrations were introduced. Legacy principals can contain:
  • credentials
  • service principal names
  • reply URLs
  • other properties, but no app registration

Permissions, scopes and consent

Identity uses a fairly standard OAuth 2.0 scopes design. Requested scopes are included in requests made to the /authorize endpoint.

There are two kinds of permissions:

• Delegated access (user-restricted)
  User or admin consent. Access to the data owned by the signed in user.
• App-only access (app-restricted)
  Admin only consent. Access to requested data from all users.

There are three kinds of consent:

• Static user consent
  All required scopes requested on initial login. Results in long lists of permissions to consent to.
• Incremental and dynamic user consent
  Allows apps to just request the scopes that are needed right now, building up consent as the user uses more features. Incompatible with permissions that require admin consent because admin consent is necessarily static.
• Admin consent
  Wholesale consent done on behalf of an organisation. Required for some high-privilege permissions.

When making an OIDC or OAuth authz request, an app requests scopes via the scope query parameter: a space separated list of requested scopes. Microsoft checks if the user has consented in the past or if an admin has consented on behalf of the user and prompts for consent if neither requirement is met.

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

• Requesting:
  • Graph Calendars.Read
  • Graph Mail.Send

Conditional access

Conditional access is a defence-in-depth strategy which allows developers to protect services in a number of ways:

• Multifactor authentication
• IP range and location restrictions
• Intune enrolled devices only (?)

Often, using conditional access doesn't require any developer changes. However, there are some scenarios which may require developers to handle specific challenge from requested resources. Consider the following scenario as an example:

You're building an app that uses a middle tier service to access a downstream API. An enterprise customer at the company using this app applies a policy to the downstream API. When an end user signs in, the app requests access to the middle tier and sends the token. The middle tier performs on-behalf-of flow to request access to the downstream API. At this point, a claims "challenge" is presented to the middle tier. The middle tier sends the challenge back to the app, which needs to comply with the Conditional Access policy.

Specifically, additional development to support conditional access challenges will be required for the following scenarios:

• Apps performing the on-behalf-of flow
• Apps accessing multiple services/resources
• Single-page apps using MSAL.js (Microsoft Authentication Library)
• Web apps calling a resource