Microsoft identity platform

1. Microsoft identity platform

Previously, you saw how Microsoft Entra ID manages who can sign in and what they can do. But what if an application needs access, either on behalf of a user or on its own? That’s where the Microsoft Identity Platform comes in.

2. What is the Microsoft identity platform?

The Microsoft Identity Platform helps apps manage sign-ins and control access. It builds on Microsoft Entra ID as the foundation. Entra ID provides the core identity service, while the Identity Platform is the developer layer that lets apps prove identity and request access.

3. How it works?

The Microsoft identity platform supports two key standards. First, OAuth 2.0 works like a permission slip. It lets apps do only what you approve, such as reading your calendar. Then, OpenID Connect adds identity, like showing an ID card, so the app knows it’s you. It works with different account types, including work or school, personal Microsoft accounts, and even social logins.

4. Key tools of the Microsoft identity platform

Key tools include MSAL for tokens, App Registration for setup, and Microsoft Graph API to access users, groups, and resources.

5. App registration

When you want your app to use Entra ID, the first step is to register it. You can pick single-tenant if it’s only for your organization, or multi-tenant if it should work with others. Registration creates two things behind the scenes: an application object and a service principal. Then, you can add secrets, certificates, and customize things like scopes or branding.

6. Application object

Think of the Application object as the blueprint of an app like the master design for a key. It is created in the home tenant, where it lives permanently. The Application object defines the rules for authentication and access.

7. Example: application object in PeopleSphere

For example, when PeopleSphere builds an HR app, its Application object lives in their tenant.

8. Service principal

A Service principal is the instance of an application in a specific tenant. It acts like a working copy of the original key, customized for that tenant, with its own specific permissions. Each customer who uses the app gets their own Service principal in their tenant.

9. Example: service principal in DataCamp

For example, when DataCamp uses PeopleSphere’s HR app, Azure creates a Service principal in DataCamp’s tenant.

10. Types of service principal

There are three types of service principals: First, Application, created through app registration, using secrets or certificates. Next, Managed Identity, automatically managed by Azure, no secrets needed. And finally,Legacy, used by older apps.

11. Permissions

Apps often need permission to access things like your calendar or contacts. OAuth 2.0 handles this by using scopes which are specific permission requests. Think of a scope like a permission slip: for example, Calendars.Read means can I view your calendar?

12. Delegated permissions

There are two permission types: First, Delegated permissions which are used when a signed-in user is involved. For instance, PeopleSphere schedules meetings for DataCamp users.

13. App-only permissions

Next, App only permissions are for background apps that run without a user. For instance, PeopleSphere automatically syncs employee records nightly. In both cases, these permissions need to be approved. That’s where consent comes in.

14. Consent

Consent is the user’s or admin’s approval that lets an app use specific permissions. There are three main types: Static consent is set up during app registration. Next Incremental consent lets apps ask for more access as needed. and finally admin consent is required for high privilege access.

15. Let's practice!

Now that you’ve learned the core ideas, let’s try them out in practice.

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.