Security

OAuth 2.0: grant flow

1. Client requests authorization from the resource owner (usually the user). 2. If the user gives authorization, the client passes the authorization grant to the authorization server. 3. If the grant is valid, the authorization server returns an access token, possibly alongside a refresh and/or ID token. 4. The client now uses that access token to access the resource server.

AAD: Application object example

1. Is the process of creating the application and service principal objects in the application's home tenant. 2. When Contoso and Fabrikam administrators complete consent, a service principal object is created in their company's Azure AD tenant and assigned the permissions that the administrator granted. Also note that the HR app could be configured/designed to allow consent by users for individual use. 3. The consumer tenants of the HR application (Contoso and Fabrikam) each have their own service principal object. Each represents their use of an instance of the application at runtime, governed by the permissions consented by the respective administrator.

AD: Security Tokens

A centralized identity provider is especially useful for apps that have users located around the globe who don't necessarily sign in from the enterprise's network. The Microsoft identity platform authenticates users and provides security tokens, such as access tokens, refresh tokens, and ID tokens. Security tokens allow a client application to access protected resources on a resource server.

AD: permissions

A client application gains access to a resource server by declaring permission requests. Two types are available: - Delegated permissions, which specify scope-based access using delegated authorization from the signed-in resource owner, are presented to the resource at run-time as "scp" claims in the client's access token. - Application permissions, which specify role-based access using the client application's credentials/identity, are presented to the resource at run-time as "roles" claims in the client's access token. Permission requests are configured on the API permissions page for an application in the Azure portal, by selecting the desired "Delegated Permissions" and "Application Permissions" (the latter requires membership in the Global Admin role). Because a public client can't securely maintain credentials, it can only request delegated permissions, while a confidential client has the ability to request both delegated and application permissions. The client's application object stores the declared permissions in its requiredResourceAccess property.

OAuth 2.0: Public Client

A client application is considered public when an end user could possibly view and modify the code. This includes Single-Page Apps (SPAs) or any mobile or native applications. In both cases, the application can't keep secrets from malicious users.

AD: application manifest

A feature provided by the Azure portal, which produces a JSON representation of the application's identity configuration, used as a mechanism for updating its associated Application and ServicePrincipal entities.

AD: security token

A signed document containing claims, such as an OAuth2 token or SAML 2.0 assertion. For an OAuth2 authorization grant, an access token (OAuth2), refresh token, and an ID Token are types of security tokens, all of which are implemented as a JSON Web Token (JWT)

AD: native client

A type of client application that is installed natively on a device. Since all code is executed on a device, it is considered a "public" client due to its inability to store credentials privately/confidentially.

AD: access token

A type of security token issued by an authorization server, and used by a client application in order to access a protected resource server. Typically in the form of a JSON Web Token (JWT), the token embodies the authorization granted to the client by the resource owner, for a requested level of access. The token contains all applicable claims about the subject, enabling the client application to use it as a form of credential when accessing a given resource. This also eliminates the need for the resource owner to expose credentials to the client. Access tokens are only valid for a short period of time and cannot be revoked. An authorization server may also issue a refresh token when the access token is issued. Refresh tokens are typically provided only to confidential client applications. Access tokens are sometimes referred to as "User+App" or "App-Only", depending on the credentials being represented. For example, when a client application uses the: - "Authorization code" authorization grant, the end user authenticates first as the resource owner, delegating authorization to the client to access the resource. The client authenticates afterward when obtaining the access token. The token can sometimes be referred to more specifically as a "User+App" token, as it represents both the user that authorized the client application, and the application. - "Client credentials" authorization grant, the client provides the sole authentication, functioning without the resource-owner's authentication/authorization, so the token can sometimes be referred to as an "App-Only" token.

AD vs AAD: Users: Provisioning external users

AD: Organizations create external users manually as regular users in a dedicated external AD forest, resulting in administration overhead to manage the lifecycle of external identities (guest users) AAD: Azure AD provides a special class of identity to support external identities. Azure AD B2B will manage the link to the external user identity to make sure they are valid.

AD vs AAD: Users: Provisioning internal users

AD: Organizations create internal users manually or use an in-house or automated provisioning system, such as the Microsoft Identity Manager, to integrate with an HR system. AAD: - Existing AD organizations use Azure AD Connect to sync identities to the cloud. - Azure AD adds support to automatically create users from cloud HR systems. - Azure AD can provision identities in SCIM enabled SaaS apps to automatically provide apps with the necessary details to allow access for users.

AD vs AAD: Devices: Mobile

AD: Active Directory doesn't natively support mobile devices without third-party solutions. AAD: Microsoft's mobile device management solution, Microsoft Intune, is integrated with Azure AD. Microsoft Intune provides device state information to the identity system to evaluate during authentication.

AD vs AAD: Devices: Linux/Unix workloads

AD: Active Directory doesn't natively support non-Windows without third-party solutions, although Linux machines can be configured to authenticate with Active Directory as a Kerberos realm. AAD: Linux/Unix VMs can use managed identities to access the identity system or resources. Some organizations, migrate these workloads to cloud container technologies, which can also use managed identities.

AD vs AAD: Apps: SaaS apps

AD: Active Directory doesn't support SaaS apps natively and requires federation system, such as AD FS. AAD: SaaS apps supporting OAuth2, SAML, and WS-* authentication can be integrated to use Azure AD for authentication.

AD vs AAD: Apps: Infrastructure apps

AD: Active Directory forms the basis for many infrastructure on-premises components, for example, DNS, DHCP, IPSec, WiFi, NPS, and VPN access. AAD: In a new cloud world, Azure AD, is the new control plane for accessing apps versus relying on networking controls. When users authenticate, Conditional access (CA), will control which users, will have access to which apps under required conditions.

AD vs AAD: Devices: Windows servers

AD: Active Directory provides strong management capabilities for on-premises Windows servers using Group Policy or other management solutions. AAD: Windows servers virtual machines in Azure can be managed with Azure AD Domain Services. Managed identities can be used when VMs need access to the identity system directory or resources.

AD vs AAD: Devices: Windows desktops

AD: Active Directory provides the ability to domain join Windows devices to manage them using Group Policy, System Center Configuration Manager, or other third-party solutions. AAD: Windows devices can be joined to Azure AD. Conditional access can check if a device is Azure AD joined as part of the authentication process. Windows devices can also be managed with Microsoft Intune. In this case, conditional access, will consider whether a device is compliant (for example, up-to-date security patches and virus signatures) before allowing access to the apps.

AD vs AAD: Users: Entitlement management and groups

AD: Administrators make users members of groups. App and resource owners then give groups access to apps or resources. AAD: Groups are also available in Azure AD and administrators can also use groups to grant permissions to resources. In Azure AD, administrators can assign membership to groups manually or use a query to dynamically include users to a group. Administrators can use Entitlement management in Azure AD to give users access to a collection of apps and resources using workflows and, if necessary, time-based criteria.

AD vs AAD: Users: Credential management

AD: Credentials in Active Directory are based on passwords, certificate authentication, and smartcard authentication. Passwords are managed using password policies that are based on password length, expiry, and complexity. AAD: Azure AD uses intelligent password protection for cloud and on-premises. Protection includes smart lockout plus blocking common and custom password phrases and substitutions. Azure AD significantly boosts security through Multi-factor authentication and passwordless technologies, like FIDO2. Azure AD reduces support costs by providing users a self-service password reset system.

AD vs AAD: Apps: Traditional and legacy apps

AD: Most on-premises apps use LDAP, Windows-Integrated Authentication (NTLM and Kerberos), or Header-based authentication to control access to users. AAD: Azure AD can provide access to these types of on-premises apps using Azure AD application proxy agents running on-premises. Using this method Azure AD can authenticate Active Directory users on-premises using Kerberos while you migrate or need to coexist with legacy apps.

AD vs AAD: Apps: Line of business (LOB) apps with modern authentication

AD: Organizations can use AD FS with Active Directory to support LOB apps requiring modern authentication. AAD: LOB apps requiring modern authentication can be configured to use Azure AD for authentication.

AD vs AAD: Users: Admin management

AD: Organizations will use a combination of domains, organizational units, and groups in AD to delegate administrative rights to manage the directory and resources it controls. AAD: Azure AD provides built-in roles with its Azure AD role-based access control (Azure AD RBAC) system, with limited support for creating custom roles to delegate privileged access to the identity system, the apps, and resources it controls. Managing roles can be enhanced with Privileged Identity Management (PIM) to provide just-in-time, time-restricted, or workflow-based access to privileged roles.

AD vs AAD: Apps: Mid-tier/Daemon services

AD: Services running in on-premises environments normally use AD service accounts or group Managed Service Accounts (gMSA) to run. These apps will then inherit the permissions of the service account. AAD: Azure AD provides managed identities to run other workloads in the cloud. The lifecycle of these identities is managed by Azure AD and is tied to the resource provider can't be used for other purposes to gain backdoor access.

AAD: Application object

An Azure AD application is defined by its one and only application object, which resides in the Azure AD tenant where the application was registered (known as the application's "home" tenant). An application object is used as a template or blueprint to create one or more service principal objects. A service principal is created in every tenant where the application is used. Similar to a class in object-oriented programming, the application object has some static properties that are applied to all the created service principals (or application instances). The application object describes three aspects of an application: - how the service can issue tokens in order to access the application - resources that the application might need to access - and the actions that the application can take.

AD: Security Tokens: Access token

An access token is a security token that's issued by an authorization server as part of an OAuth 2.0 flow. It contains information about the user and the resource for which the token is intended. The information can be used to access web APIs and other protected resources. Access tokens are validated by resources to grant access to a client app.

AD: Tenant

An instance of an Azure AD directory is referred to as an Azure AD tenant. It provides several features, including: - a registry service for integrated applications - authentication of user accounts and registered applications - REST endpoints required to support various protocols including OAuth2 and SAML, including the authorization endpoint, token endpoint and the "common" endpoint used by multi-tenant applications. Azure AD tenants are created/associated with Azure and Microsoft 365 subscriptions during sign-up, providing Identity & Access Management features for the subscription. Azure subscription administrators can also create additional Azure AD tenants via the Azure portal.

AAD: Modifying and Deleting applications

Any changes that you make to your application object are also reflected in its service principal object in the application's home tenant only (the tenant where it was registered). This means that deleting an application object will also delete its home tenant service principal object. However, restoring that application object will not restore its corresponding service principal. For multi-tenant applications, changes to the application object are not reflected in any consumer tenants' service principal objects, until the access is removed through the Application Access Panel and granted again.

AAD: Features

Application management: Manage your cloud and on-premises apps using Application Proxy, single sign-on, the My Apps portal (also known as the Access panel), and Software as a Service (SaaS) apps. Authentication: Manage Azure Active Directory self-service password reset, Multi-Factor Authentication, custom banned password list, and smart lockout. Azure Active Directory for developers: Build apps that sign in all Microsoft identities, get tokens to call Microsoft Graph, other Microsoft APIs, or custom APIs. For more information, see Microsoft identity platform (Azure Active Directory for developers).Business-to-Business (B2B)Manage your guest users and external partners, while maintaining control over your own corporate data. Business-to-Customer (B2C): Customize and control how users sign up, sign in, and manage their profiles when using your apps. For more information, see Azure Active Directory B2C documentation. Conditional Access: Manage access to your cloud apps. Device Management: Manage how your cloud or on-premises devices access your corporate data. Domain services: Join Azure virtual machines to a domain without using domain controllers. Enterprise users: Manage license assignment, access to apps, and set up delegates using groups and administrator roles. Hybrid identity: Use Azure Active Directory Connect and Connect Health to provide a single user identity for authentication and authorization to all resources, regardless of location (cloud or on-premises). Identity governance: Manage your organization's identity through employee, business partner, vendor, service, and app access controls. You can also perform access reviews. Identity protection: Detect potential vulnerabilities affecting your organization's identities, configure policies to respond to suspicious actions, and then take appropriate action to resolve them. Managed identities for Azure resources: Provides your Azure services with an automatically managed identity in Azure AD that can authenticate any Azure AD-supported authentication service, including Key Vault. Privileged identity management (PIM): Manage, control, and monitor access within your organization. This feature includes access to resources in Azure AD and Azure, and other Microsoft Online Services, like Microsoft 365 or Intune. Reports and monitoring: Gain insights into the security and usage patterns in your environment.

AAD: Service principal: Application

Application service principal is the local representation, or application instance, of a global application object in a single tenant or directory. In this case, a service principal is a concrete instance created from the application object and inherits certain properties from that application object. A service principal is created in each tenant where the application is used and references the globally unique app object. The service principal object defines what the app can actually do in the specific tenant, who can access the app, and what resources the app can access. When an application is given permission to access resources in a tenant (upon registration or consent), a service principal object is created. You can also create service principal objects in a tenant using Azure PowerShell, Azure CLI, Microsoft Graph, the Azure portal, and other tools. When using the portal, a service principal is created automatically when you register an application.

SSO Methods: OpenID Connect and OAuth

Application types: Cloud only When to use: Use OpenID Connect and OAuth when developing a new application. This protocol simplifies application configuration, has easy-to-use SDKs, and enables your application to use MS Graph.

SSO Methods: SAML

Application types: cloud and on-premises When to use: Choose SAML whenever possible for existing applications that do not use OpenID Connect or OAuth. SAML works for applications that authenticate using one of the SAML protocols.

SSO Methods: Linked

Application types: cloud and on-premises When to use: Choose linked sign-on when the application is configured for single sign-on in another identity provider service. This option doesn't add single sign-on to the application. However, the application might already have single sign-on implemented using another service such as Active Directory Federation Services.

SSO Methods: Password-based

Application types: cloud and on-premises When to use: Choose password-based when the application authenticates with username and password. Password-based single sign-on enables secure application password storage and replay using a web browser extension or mobile app. This method uses the existing sign-in process provided by the application, but enables an administrator to manage the passwords.

SSO Methods: Integrated Windows Authentication (IWA)

Application types: on-premises only When to use: Choose IWA single sign-on for applications that use Integrated Windows Authentication (IWA), or claims-aware applications. For IWA, the Application Proxy connectors use Kerberos Constrained Delegation (KCD) to authenticate users to the application.

SSO Methods: Header-based

Application types: on-premises only When to use: Use header-based single sign-on when the application uses headers for authentication. Header-based single sign-on requires PingAccess for Azure AD. Application Proxy uses Azure AD to authenticate the user and then passes traffic through the connector.

AD: Authentication

Authentication is the process of proving that you are who you say you are. It's sometimes shortened to AuthN. The Microsoft identity platform uses the OpenID Connect protocol for handling authentication.

AD: Authorization

Authorization is the act of granting an authenticated party permission to do something. It specifies what data you're allowed to access and what you can do with that data. Authorization is sometimes shortened to AuthZ. The Microsoft identity platform uses the OAuth 2.0 protocol for handling authorization.

Azure AD: Group Accounts

Azure AD allows you to define two different types of groups. Security groups: These are the most common and are used to manage member and computer access to shared resources for a group of users. For example, you can create a security group for a specific security policy. By doing it this way, you can give a set of permissions to all the members at once, instead of having to add permissions to each member individually. This option requires an Azure AD administrator. Microsoft 365 groups: These groups provide collaboration opportunities by giving members access to a shared mailbox, calendar, files, SharePoint site, and more. This option also lets you give people outside of your organization access to the group. This option is available to users as well as admins. There are different ways you can assign access rights: Assigned. Lets you add specific users to be members of this group and to have unique permissions. Dynamic User. Lets you use dynamic membership rules to automatically add and remove members. If a member's attributes change, the system looks at your dynamic group rules for the directory to see if the member meets the rule requirements (is added) or no longer meets the rules requirements (is removed). Dynamic Device (Security groups only). Lets you use dynamic group rules to automatically add and remove devices. If a device's attributes change, the system looks at your dynamic group rules for the directory to see if the device meets the rule requirements (is added) or no longer meets the rules requirements (is removed).

Azure AD B2B

Azure Active Directory (Azure AD) business-to-business (B2B) collaboration lets you securely share your company's applications and services with guest users from any other organization, while maintaining control over your own corporate data. Work safely and securely with external partners, large or small, even if they don't have Azure AD or an IT department. A simple invitation and redemption process lets partners use their own credentials to access your company's resources. Developers can use Azure AD business-to-business APIs to customize the invitation process or write applications like self-service sign-up portals. With Azure AD B2B: - There is no external administrative overhead for your organization. - The partner uses their own identities and credentials; Azure AD is not required. - You don't need to manage external accounts or passwords. - You don't need to sync accounts or manage account lifecycles.

Azure AD: Self-Service Password Reset (SSPR) Writeback

Azure Active Directory (Azure AD) self-service password reset (SSPR) lets users reset their passwords in the cloud, but most companies also have an on-premises Active Directory Domain Services (AD DS) environment where their users exist. Password writeback is a feature enabled with Azure AD Connect that allows password changes in the cloud to be written back to an existing on-premises directory in real time. In this configuration, as users change or reset their passwords using SSPR in the cloud, the updated passwords also written back to the on-premises AD DS environment. Password writeback is supported in environments that use the following hybrid identity models: - Password hash synchronization - Pass-through authentication - Active Directory Federation Services

Azure AD B2C

Azure Active Directory B2C provides business-to-customer identity as a service. Your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs. Azure Active Directory B2C (Azure AD B2C) is a customer identity access management (CIAM) solution capable of supporting millions of users and billions of authentications per day. It takes care of the scaling and safety of the authentication platform, monitoring and automatically handling threats like denial-of-service, password spray, or brute force attacks. With Azure AD B2C: - You invite users from other social media Identity Tenants into your own organization tenant. - User provisioning is done by the invited party; you are in control to invite the other side's users. - Standards-based authentication protocols are used including OpenID Connect, OAuth 2.0, and SAML. Integrates with most modern applications and commercial off-the-shelf software. - Provides a directory that can hold 100 custom attributes per user. However, you can also integrate with external systems. For example, use Azure AD B2C for authentication, but delegate to an external customer relationship management (CRM) or customer loyalty database as the source of truth for customer data - Facilitate identity verification and proofing by collecting user data, then passing it to a third party system to perform validation, trust scoring, and approval for user account creation.

Management Groups

Azure management groups provide a level of scope above subscriptions. You organize subscriptions into containers called management groups and apply your governance conditions to the management groups. Management group enable: - Organizational alignment for your Azure subscriptions through custom hierarchies and grouping. - Targeting of policies and spend budgets across subscriptions and inheritance down the hierarchies. - Compliance and cost reporting by organization (business/teams).

AD: Security Tokens: Refresh token

Because access tokens are valid for only a short period of time, authorization servers will sometimes issue a refresh token at the same time the access token is issued. The client application can then exchange this refresh token for a new access token when needed.

Azure AD: Conditional Access: Common Decisions

Block access Most restrictive decision Grant access Least restrictive decision, can still require one or more of the following options: - Require multi-factor authentication - Require device to be marked as compliant - Require Hybrid Azure AD joined device - Require approved client app - Require app protection policy (preview)

OAuth 2.0: Authorization Code flow with PKCE

For web/native/mobile applications, the client secret can't be stored in the application because it could easily be exposed. Additionally, mobile redirects use app:// protocols, which are prone to interception. Therefore native apps should make use of Proof Key for Code Exchange (PKCE), which acts like a secret but isn't hard-coded, to keep the Authorization Code flow secure. PKCE is an extension to the regular Authorization Code flow, so the flow is very similar, except that PKCE elements are included at various steps in the flow. Note: The Authorization Code flow with PKCE doesn't support refresh tokens for SPAs and other browser-based apps. The PKCE-enhanced Authorization Code flow requires your application to generate a cryptographically random key called a "code verifier". A "code challenge" is then created from the verifier, and this challenge is passed along with the request for the authorization code. When the authorization code is sent in the access token request, the code verifier is sent as part of the request. The authorization server recomputes the challenge from the verifier using an agreed-upon hash algorithm and then compares that. If the two code challenges and verifier match, then it knows that both requests were sent by the same client. A rogue app could only intercept the authorization code, but it wouldn't have access to the code challenge or verifier, since they are both sent over HTTPS.

AD: Security Tokens: ID token

ID tokens are sent to the client application as part of an OpenID Connect flow. They can be sent alongside or instead of an access token. ID tokens are used by the client to authenticate the user.

AAD: Azure AD Concepts

Identity. A thing that can get authenticated. An identity can be a user with a username and password. Identities also include applications or other servers that might require authentication through secret keys or certificates. Account. An identity that has data associated with it. You cannot have an account without an identity. Azure AD Account. An identity created through Azure AD or another Microsoft cloud service, such as Microsoft 365. Identities are stored in Azure AD and accessible to your organization's cloud service subscriptions. This account is also sometimes called a Work or school account. Azure subscription. Used to pay for Azure cloud services. You can have many subscriptions and they're linked to a credit card. Azure tenant. A dedicated and trusted instance of Azure AD that's automatically created when your organization signs up for a Microsoft cloud service subscription, such as Microsoft Azure, Microsoft Intune, or Microsoft 365. An Azure tenant represents a single organization. Azure AD directory. Each Azure tenant has a dedicated and trusted Azure AD directory. The Azure AD directory includes the tenant's users, groups, and apps and is used to perform identity and access management functions for tenant resources.

AAD: Application registration

In order to delegate Identity and Access Management functions to Azure AD, an application must be registered with an Azure AD tenant. When you register your application with Azure AD, you are creating an identity configuration for your application that allows it to integrate with Azure AD. When you register an app in the Azure portal, you choose whether it's a single tenant (only accessible in your tenant) or multi-tenant (accessible in other tenants) and can optionally set a redirect URI (where the access token is sent to). When you've completed the app registration, you have a globally unique instance of the app (the application object) which lives within your home tenant or directory. You also have a globally unique ID for your app (the app or client ID). In the portal, you can then add secrets or certificates and scopes to make your app work, customize the branding of your app in the sign-in dialog, and more. If you register an application in the portal, an application object as well as a service principal object are automatically created in your home tenant. If you register/create an application using the Microsoft Graph APIs, creating the service principal object is a separate step.

Azure AD: Domains and Custom Domains

Initial domain name: By default, when you create an Azure subscription an Azure AD domain is created for you. This instance of the domain has initial domain name in the form domainname.onmicrosoft.com. The initial domain name, while fully functional, is intended primarily to be used as a bootstrapping mechanism until a custom domain name is verified. Custom domain name: Although the initial domain name for a directory can't be changed or deleted, you can add any routable custom domain name you control. This simplifies the user sign-on experience by allowing user to logon with credentials they are familiar with. For example, a contosogold.onmicrosoft.com, could be assigned a simpler custom domain name of contosogold.com. Practical information about domain names - Only a global administrator can perform domain management tasks in Azure AD, by default this is the user who created the subscription. - Domain names in Azure AD are globally unique. If one Azure AD directory has verified a domain name, then no other Azure AD directory can verify or use that same domain name. - Before a custom domain name can be used by Azure AD, the custom domain name must be added to your directory and verified. This is covered in the next topic.

AD: Validating security tokens

It's up to the app for which the token was generated, the web app that signed in the user, or the web API being called to validate the token. The token is signed by the authorization server with a private key. The authorization server publishes the corresponding public key. To validate a token, the app verifies the signature by using the authorization server public key to validate that the signature was created using the private key. Tokens are valid for only a limited amount of time. Usually, the authorization server provides a pair of tokens, such as: - An access token, which accesses the application or protected resource. - A refresh token, which is used to refresh the access token when the access token is close to expiring. Access tokens are passed to a web API as the bearer token in the Authorization header. An app can provide a refresh token to the authorization server. If the user access to the app wasn't revoked, it will get back a new access token and a new refresh token. This is how the scenario of someone leaving the enterprise is handled. When the authorization server receives the refresh token, it won't issue another valid access token if the user is no longer authorized.

AAD: Service principal: Legacy

Legacy service principal represents a legacy app (an app created before app registrations were introduced or created through legacy experiences). A legacy service principal can have credentials, service principal names, reply URLs, and other properties which are editable by an authorized user, but does not have an associated app registration. The service principal can only be used in the tenant where it was created.

AD: Scopes

Like roles, scopes provide a way for a resource server to govern access to its protected resources. Scopes are used to implement scope-based access control, for a client application that has been given delegated access to the resource by its owner. Scopes are resource-defined strings (for example "Mail.Read", "Directory.ReadWrite.All"), managed in the Azure portal via the resource's application manifest, and stored in the resource's oauth2Permissions property. The Azure portal is also used to configure client application delegated permissions to access a scope. A best practice naming convention, is to use a "resource.operation.constraint" format.

AD: roles

Like scopes, roles provide a way for a resource server to govern access to its protected resources. There are two types: - a user role implements role-based access control for users/groups that require access to the resource - an application role implements the same for client applications that require access. Roles are resource-defined strings (for example "Expense approver", "Read-only", "Directory.ReadWrite.All"), managed in the Azure portal via the resource's application manifest, and stored in the resource's appRoles property. The Azure portal is also used to assign users to "user" roles, and configure client application permissions to access an "application" role.

AAD: Service principal: Managed Identity

Managed identities eliminate the need for developers to manage credentials. Managed identities provide an identity for applications to use when connecting to resources that support Azure AD authentication. When a managed identity is enabled, a service principal representing that managed identity is created in your tenant. Service principals representing managed identities can be granted access and permissions, but cannot be updated or modified directly.

Azure AD: Conditional Access: Common Applied Policies

Many organizations have common access concerns that Conditional Access policies can help with such as: - Requiring multi-factor authentication for users with administrative roles - Requiring multi-factor authentication for Azure management tasks - Blocking sign-ins for users attempting to use legacy authentication protocols - Requiring trusted locations for Azure Multi-Factor Authentication registration - Blocking or granting access from specific locations - Blocking risky sign-in behaviors - Requiring organization-managed devices for specific applications

OAuth 2.0

OAuth 2.0 is a standard that apps use to provide client applications with access. If you would like to grant access to your application data in a secure way, then you want to use the OAuth 2.0 protocol. The OAuth 2.0 protocol controls authorization to access a protected resource, like your web app, native app, or API service.

Microsoft identity platform: Protocol Comparison

OAuth versus OpenID Connect: The platform uses OAuth for authorization and OpenID Connect (OIDC) for authentication. OpenID Connect is built on top of OAuth 2.0, so the terminology and flow are similar between the two. You can even both authenticate a user (through OpenID Connect) and get authorization to access a protected resource that the user owns (through OAuth 2.0) in one request. OAuth versus SAML: The platform uses OAuth 2.0 for authorization and SAML for authentication. OpenID Connect versus SAML: The platform uses both OpenID Connect and SAML to authenticate a user and enable single sign-on. SAML authentication is commonly used with identity providers such as Active Directory Federation Services (AD FS) federated to Azure AD, so it's often used in enterprise applications. OpenID Connect is commonly used for apps that are purely in the cloud, such as mobile apps, websites, and web APIs.

AD: token endpoint

One of the endpoints implemented by the authorization server to support OAuth2 authorization grants. Depending on the grant, it can be used to acquire an access token (and related "refresh" token) to a client, or ID token when used with the OpenID Connect protocol.

OpenID Connect

OpenID Connect is an authentication standard built on top of OAuth 2.0. It adds an additional token called an ID token. OpenID Connect also standardizes areas that OAuth 2.0 leaves up to choice, such as scopes, endpoint discovery, and dynamic registration of clients. The high-level flow looks the same for both OpenID Connect and regular OAuth 2.0 flows. The primary difference is that an OpenID Connect flow results in an ID token, in addition to any access or refresh tokens.

OpenID Connect: Key terms

OpenID provider: The authorization server that issues the ID token. end user: Whose information is contained in the ID token relying party: The client application that requests the ID token ID token: is issued by the OpenID Provider and contains information about the end user in the form of claims. claim: is a piece of information about the end user.

Resource Groups

Resource groups are a fundamental element of the Azure platform. A resource group is a logical container for resources deployed on Azure. These resources are anything you create in an Azure subscription like virtual machines, Application Gateways, and CosmosDB instances. All resources must be in a resource group and a resource can only be a member of a single resource group. Many resources can be moved between resource groups with some services having specific limitations or requirements to move. Resource groups can't be nested. Before any resource can be provisioned, you need a resource group for it to be placed in. If you delete a resource group, all resources contained within are also deleted.

OAuth 2.0: Authorization Code flow

The Authorization Code flow is best used by server-side apps where the source code isn't publicly exposed. The apps should be server-side because the request that exchanges the authorization code for a token requires a client secret, which has to be stored in your client. The server-side app requires an end user, however, because it relies on interaction with the end user's web browser, which redirects the user and then receives the authorization code.

OAuth 2.0: Client Credentials flow

The Client Credentials flow is intended for server-side (AKA "confidential") client applications with no end user, which normally describes machine-to-machine communication. The application must be server-side because it must be trusted with the client secret, and since the credentials are hard-coded, it can't be used by an actual end user. It involves a single, authenticated request to the /token endpoint, which returns an access token. Note: The Client Credentials flow doesn't support refresh tokens.

OAuth 2.0: Implicit flow

The Implicit flow is intended for applications where the confidentiality of the client secret can't be guaranteed. In this flow, the client doesn't make a request to the /token endpoint, but instead receives the access token directly from the /authorize endpoint. The client must be capable of interacting with the resource owner's user agent and also capable of receiving incoming requests (through redirection) from the authorization server. Note: Because it is intended for less-trusted clients, the Implicit flow doesn't support refresh tokens. Important: For Single-Page Applications (SPA) running in modern browsers that support Web Crypto for PKCE, we recommend using the Authorization Code flow with PKCE instead of the Implicit flow for maximum security. If support for older browsers is required, the Implicit flow provides a working solution.

AD: JSON Web Tokens (JWT) & Claims

The Microsoft identity platform implements security tokens as JSON Web Tokens (JWTs) that contain claims. Since JWTs are used as security tokens, this form of authentication is sometimes called JWT authentication. A claim provides assertions about one entity, such as a client application or resource owner, to another entity, such as a resource server. A claim might also be referred to as a JWT claim or a JSON Web Token claim. Applications can use claims for various tasks, such as to: - Validate the token. - Identify the token subject's tenant. - Display user information. - Determine the subject's authorization. A claim consists of key-value pairs that provide information such as the: - Security Token Server that generated the token. - Date when the token was generated. - Subject (such as the user--except for daemons). - Audience, which is the app for which the token was generated. - App (the client) that asked for the token. In the case of web apps, this app might be the same as the audience.

OAuth 2.0: Resource Owner Password flow

The Resource Owner Password flow is intended for use cases where you control both the client application and the resource that it is interacting with. It requires that the client can store a client secret and can be trusted with the resource owner's credentials, and so is most commonly found in clients made for online services, like the Facebook client applications that interact with the Facebook service. It doesn't require redirects like the Authorization Code or Implicit flows, and involves a single authenticated call to the /token endpoint.

OAuth 2.0: SAML 2.0 Assertion flow

The SAML 2.0 Assertion flow is intended for a client app that wants to use an existing trust relationship without a direct user approval step at the authorization server. It enables a client application to obtain an authorization from a valid, signed SAML assertion from the SAML Identity Provider. The client app can then exchange it for an OAuth access token from the OAuth authorization server. For example, this flow is useful when you want to fetch data from APIs that only support delegated permissions without prompting the user for credentials. To use a SAML 2.0 Assertion as an authorization grant, the client makes a SAML request to the Identity Provider and the Identity Provider sends the SAML 2.0 Assertion back in the response. The client then makes a request for an access token with the urn:ietf:params:oauth:grant-type:saml2-bearer grant type and includes the assertion parameter. The value of the assertion parameter is the SAML 2.0 assertion that is Base64 encoded. You can send only one SAML assertion in that request.

AAD: Application Objects & Service Principals

The application object is the global representation of your application for use across all tenants, and the service principal is the local representation for use in a specific tenant. The application object serves as the template from which common and default properties are derived for use in creating corresponding service principal objects. An application object therefore has a 1:1 relationship with the software application, and a 1:many relationship with its corresponding service principal object(s). A service principal must be created in each tenant where the application is used, enabling it to establish an identity for sign-in and/or access to resources being secured by the tenant. A single-tenant application has only one service principal (in its home tenant), created and consented for use during application registration. A multi-tenant application also has a service principal created in each tenant where a user from that tenant has consented to its use.

Azure AD: Conditional Access

The modern security perimeter now extends beyond an organization's network to include user and device identity. Organizations can utilize these identity signals as part of their access control decisions. Conditional Access is the tool used by Azure Active Directory to bring signals together, to make decisions, and enforce organizational policies. Conditional Access is at the heart of the new identity driven control plane. By using Conditional Access policies, you can apply the right access controls when needed to keep your organization secure and stay out of your user's way when not needed. Conditional Access policies are enforced after the first-factor authentication has been completed. Conditional Access is not intended as an organization's first line of defense for scenarios like denial-of-service (DoS) attacks, but can use signals from these events to determine access.

AD: application ID (client ID)

The unique identifier Azure AD issues to an application registration that identifies a specific application and the associated configurations. This application ID (client ID) is used when performing authentication requests and is provided to the authentication libraries in development time. The application ID (client ID) is not a secret.

AAD: Service principal

To access resources that are secured by an Azure AD tenant, the entity that requires access must be represented by a security principal. This requirement is true for both users (user principal) and applications (service principal). The security principal defines the access policy and permissions for the user/application in the Azure AD tenant. This enables core features such as authentication of the user/application during sign-in, and authorization during resource access. There are three types of service principal: - application - managed identity - legacy.

Azure AD: User definition

Typically, Azure AD defines users in three ways: Cloud identities. These users exist only in Azure AD. Examples are administrator accounts and users that you manage yourself. Their source is Azure Active Directory or External Azure Active Directory if the user is defined in another Azure AD instance but needs access to subscription resources controlled by this directory. When these accounts are removed from the primary directory, they are deleted. Directory-synchronized identities. These users exist in an on-premises Active Directory. A synchronization activity that occurs via Azure AD Connect brings these users in to Azure. Their source is Windows Server AD. Guest users. These users exist outside Azure. Examples are accounts from other cloud providers and Microsoft accounts such as an Xbox LIVE account. Their source is Invited user. This type of account is useful when external vendors or contractors need access to your Azure resources. Once their help is no longer necessary, you can remove the account and all of their access.

Azure AD: Common signals for conditional access

User or group membership: Policies can be targeted to specific users and groups giving administrators fine-grained control over access. IP Location information: Organizations can create trusted IP address ranges that can be used when making policy decisions. Administrators can specify IP ranges to block or allow traffic from. Device: Users with devices of specific platforms or marked with a specific state can be used when enforcing Conditional Access policies. Application: Users attempting to access specific applications can trigger different Conditional Access policies. Real-time and calculated risk detection: Signals integration with Azure AD Identity Protection allows Conditional Access policies to identify risky sign-in behavior. Policies can then force users to perform password changes or multi-factor authentication to reduce their risk level or be blocked from access until an administrator takes manual action. Microsoft Cloud App Security (MCAS): Enables user application access and sessions to be monitored and controlled in real time, increasing visibility and control over access to and activities performed within your cloud environment.

Azure AD: Verifying Custom Domain Names

When an administrator adds a custom domain name to an Azure AD, it is initially in an unverified state. Azure AD will not allow any directory resources to use an unverified domain name. This ensures that only one directory can use a domain name, and the organization using the domain name owns that domain name. So, after adding the custom domain name, you must demonstrate ownership of the domain name. This is called verification. and is done by adding a DNS record (MX or TXT) that is provided by Azure into your company's DNS zone. Once this record is added, Azure will query the DNS domain for the presence of the record. This could take several minutes or several hours. If Azure verifies the presence of the DNS record, it will then add the domain name to the subscription.

Azure AD Connect Health

When with Azure AD, users are more productive because there's a common identity to access both cloud and on-premises resources. Ensuring the environment is reliable, so that users can access these resources, becomes a challenge. Azure AD Connect Health helps monitor and gain insights into your on-premises identity infrastructure thus ensuring the reliability of this environment. It is enabled by installing an agent on each on-premises identity server. Azure AD Connect Health for AD FS supports AD FS 2.0 on Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 and Windows Server 2016. It also supports monitoring the AD FS proxy or web application proxy servers that provide authentication support for extranet access. With an easy and quick installation of the Health Agent, Azure AD Connect Health for AD FS provides you a set of key capabilities.

Azure AD: Create and Manage Users

You can add users to Azure AD in multiple ways: 1. Syncing an on-premises Windows Server Active Directory 2. Add a new user using the portal. 3. Invite a guest user using a known email address.

Azure AD: Manage Guest Users

You can invite anyone to collaborate with your organization by adding them to your directory as a guest user. Then you can either send an invitation email that contains a redemption link or send a direct link to an app you want to share. Guest users can sign in with their own work, school, or social identities.

OAuth 2.0: Important roles

authorization server: The server that issues the access token. resource owner: Normally your application's end user that grants permission to access the resource server with an access token client: The application that requests the access token from authorization server and then passes it to the resource server resource server: Accepts the access token and must verify that it's valid. In this case this is your application.

OAuth 2.0: Important terms

grant is the authorization given (or "granted") to the client by the user. Examples of grants are authorization code and client credentials. access token is issued by the authorization server in exchange for the grant. refresh token is an optional token that is exchanged for a new access token if the access token has expired.