The most basic building block of data access requirements is the identity layer. As you've seen throughout this book, Azure Active Directory is the foundation for identity and security in the Microsoft 365 platform. Whether your organization's identity is cloud-based or is synchronized from an on-premises directory, the principles of assigning the least privilege necessary to perform the function still apply. Review the following table for the core identity concepts:
| Type | Description |
| User (Member) | This is an identity that is part of your organization. This identity may be provisioned in the service directly (cloud identity), or it may be synchronized from an on-premises directory. |
| User (Guest) | This is an identity that is created in your directory through the use of B2B services. Frequently, these identities have been created through the use of guest sharing invitations from Teams or SharePoint Online. |
| Security Group | The security group construct can be used to associate users together as a single unit for purposes of granting permissions or roles in applications. Security groups, like users, can be provisioned in the service directly or synchronized from an on-premises directory. |
| Office 365 Group | As we've discussed elsewhere in this book, Office 365 Groups are a group type of object with some special capabilities and functions, including a group mailbox, shared OneNote, and a SharePoint Team Site. Office 365 Groups can only be provisioned in the service. |
| Service Principal | An Azure service principal is a special identity that is created for a service or application to use. It frequently has a very complex password or a certificate associated with it for authentication and is usually delegated the exact permissions or roles that it needs to perform its function (unlike a standard user object, which has broad access to several services). |