The security perimeter for Microsoft 365 is often seen as defined by identity. This is because cloud workloads can exist globally and can be impossible to secure at the network edge alone. Using an identity allows for a control point, Azure Active Directory, to grant or deny access.
Azure Active Directory also allows for conditional access and integration with other services in the Microsoft clouds, other integrated clouds, and on-premises environemnts.
Applications in this context can operate in both the User and the Application Context. When an application operates as a user it has the level of permissions that the user has. If the application operates in it’s own context it will have the permissions granted by an administrator of the environment.
An application registered to operate in an Application Context is often used to run a service in the background and is given permission to operate across the span of the environment or scoped down very specifically for a single purpose. Regardless of the purpose, the application has it’s own identity, a service principal and this is used to authenticate that application against Azure Active Directory. This application can then have a secret or password, or use client certificate for authentication.
There is a third type of authentication using an external identity and an open standard but is out of scope for this workshop.