Merge pull request #239509 from MicrosoftDocs/main

Publish to live, Sunday 4 AM PST, 5/28

Author: ttorble

articles/active-directory/develop/TOC.yml

@@ -581,6 +581,12 @@
           href: ./howto-restore-app.md
 - name: Reference
   items:
+    - name: Token claims reference
+      items:
+        - name: Access token
+          href: access-token-claims-reference.md            
+        - name: SAML token
+          href: reference-saml-tokens.md
     - name: Microsoft Authentication Library (MSAL) reference
       displayName: SDK, library, msal, auth
       items:
@@ -830,8 +836,6 @@
               href: single-sign-on-saml-protocol.md
             - name: Sign out (SAML)
               href: single-sign-out-saml-protocol.md
-            - name: SAML tokens
-              href: reference-saml-tokens.md
             - name: Token exchange scenarios
               href: scenario-token-exchange-saml-oauth.md
     - name: App registration reference

articles/active-directory/develop/access-token-claims-reference.md

@@ -42,7 +42,7 @@ You can set token lifetime policies for access tokens, SAML tokens, and ID token
 
 Clients use access tokens to access a protected resource. An access token can be used only for a specific combination of user, client, and resource. Access tokens cannot be revoked and are valid until their expiry. A malicious actor that has obtained an access token can use it for extent of its lifetime. Adjusting the lifetime of an access token is a trade-off between improving system performance and increasing the amount of time that the client retains access after the user's account is disabled. Improved system performance is achieved by reducing the number of times a client needs to acquire a fresh access token.
 
-The default lifetime of an access token is variable. When issued, an access token's default lifetime is assigned a random value ranging between 60-90 minutes (75 minutes on average).  The default lifetime also varies depending on the client application requesting the token or if conditional access is enabled in the tenant. For more information, see [Access token lifetime](access-tokens.md#access-token-lifetime).
+The default lifetime of an access token is variable. When issued, an access token's default lifetime is assigned a random value ranging between 60-90 minutes (75 minutes on average).  The default lifetime also varies depending on the client application requesting the token or if conditional access is enabled in the tenant. For more information, see [Access token lifetime](access-tokens.md#token-lifetime).
 
 ### SAML tokens
 

articles/active-directory/develop/access-tokens.md

@@ -43,20 +43,20 @@ Developers have the flexibility to provide their own implementation for how role
 
 Azure AD allows you to [define app roles](./howto-add-app-roles-in-azure-ad-apps.md) for your application and assign those roles to users and other applications. The roles you assign to a user or application define their level of access to the resources and operations in your application.
 
-When Azure AD issues an access token for an authenticated user or application, it includes the names of the roles you've assigned the entity (the user or application) in the access token's [`roles`](./access-tokens.md#payload-claims) claim. An application like a web API that receives that access token in a request can then make authorization decisions based on the values in the `roles` claim.
+When Azure AD issues an access token for an authenticated user or application, it includes the names of the roles you've assigned the entity (the user or application) in the access token's [`roles`](./access-token-claims-reference.md#payload-claims) claim. An application like a web API that receives that access token in a request can then make authorization decisions based on the values in the `roles` claim.
 
 ### Groups
 
-Developers can also use [Azure AD groups](../fundamentals/active-directory-manage-groups.md) to implement RBAC in their applications, where the memberships of the user in specific groups are interpreted as their role memberships. When an organization uses Azure AD groups, a [groups claim](./access-tokens.md#payload-claims) is included in the token that specifies the identifiers of all of the groups to which the user is assigned within the current Azure AD tenant.
+Developers can also use [Azure AD groups](../fundamentals/active-directory-manage-groups.md) to implement RBAC in their applications, where the memberships of the user in specific groups are interpreted as their role memberships. When an organization uses groups, the token includes a [groups claim](./access-token-claims-reference.md#payload-claims). The group claim specifies the identifiers of all of the assigned groups of the user within the tenant.
 
 > [!IMPORTANT]
-> When working with groups, developers need to be aware of the concept of an [overage claim](./access-tokens.md#payload-claims). By default, if a user is a member of more than the overage limit (150 for SAML tokens, 200 for JWT tokens, 6 if using the implicit flow), Azure AD doesn't emit a groups claim in the token. Instead, it includes an "overage claim" in the token that indicates the consumer of the token needs to query the Microsoft Graph API to retrieve the group memberships of the user. For more information about working with overage claims, see [Claims in access tokens](./access-tokens.md#claims-in-access-tokens). It's possible to only emit groups that are assigned to an application, though [group-based assignment](../manage-apps/assign-user-or-group-access-portal.md) does require Azure Active Directory Premium P1 or P2 edition.
+> When working with groups, developers need to be aware of the concept of an [overage claim](./access-token-claims-reference.md#payload-claims). By default, if a user is a member of more than the overage limit (150 for SAML tokens, 200 for JWT tokens, 6 if using the implicit flow), Azure AD doesn't emit a groups claim in the token. Instead, it includes an "overage claim" in the token that indicates the consumer of the token needs to query the Microsoft Graph API to retrieve the group memberships of the user. For more information about working with overage claims, see [Claims in access tokens](./access-token-claims-reference.md). It's possible to only emit groups that are assigned to an application, though [group-based assignment](../manage-apps/assign-user-or-group-access-portal.md) does require Azure Active Directory Premium P1 or P2 edition.
 
 ### Custom data store
 
-App roles and groups both store information about user assignments in the Azure AD directory. Another option for managing user role information that is available to developers is to maintain the information outside of the directory in a custom data store. For example, in a SQL database, Azure Table storage, or Azure Cosmos DB for Table.
+App roles and groups both store information about user assignments in the Azure AD directory. Another option for managing user role information that is available to developers is to maintain the information outside of the directory in a custom data store. For example, in an SQL database, Azure Table storage, or Azure Cosmos DB for Table.
 
-Using custom storage allows developers extra customization and control over how to assign roles to users and how to represent them. However, the extra flexibility also introduces more responsibility. For example, there's no mechanism currently available to include this information in tokens returned from Azure AD. If developers maintain role information in a custom data store, they'll need to have the applications retrieve the roles. Retrieving the roles is typically done using extensibility points defined in the middleware available to the platform that's being used to develop the application. Developers are responsible for properly securing the custom data store.
+Using custom storage allows developers extra customization and control over how to assign roles to users and how to represent them. However, the extra flexibility also introduces more responsibility. For example, there's no mechanism currently available to include this information in tokens returned from Azure AD. Applications must retrieve the roles if role information is maintained in a custom data store. Retrieving the roles is typically done using extensibility points defined in the middleware available to the platform that's being used to develop the application. Developers are responsible for properly securing the custom data store.
 
 Using [Azure AD B2C Custom policies](../../active-directory-b2c/custom-policy-overview.md) it's possible to interact with custom data stores and to include custom claims within a token.
 

articles/active-directory/develop/configurable-token-lifetimes.md

@@ -29,9 +29,9 @@ Use the following table to learn about changes including deprecations, retiremen
 
 |Functionality, feature, or service|Change|Change date |
 |---|---|---:|
-|Microsoft Authenticator app [Number matching](../authentication/how-to-mfa-number-match.md)|Feature change|May 8, 2023|
 |[My Groups experience](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|May 2023|
 |[My Apps browser extension](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|May 2023|
+|[Microsoft Authenticator Lite for Outlook mobile](../../active-directory/authentication/how-to-mfa-authenticator-lite.md)|Feature change|Jun 9, 2023|
 |[System-preferred authentication methods](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Feature change|Sometime after GA|
 |[Azure AD Authentication Library (ADAL)](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Retirement|Jun 30, 2023|
 |[Azure AD Graph API](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-march-2023-train/ba-p/2967448)|Deprecation|Jun 30, 2023|
@@ -47,6 +47,7 @@ Use the following table to learn about changes including deprecations, retiremen
 
 |Functionality, feature, or service|Change|Change date |
 |---|---|---:|
+|Microsoft Authenticator app [Number matching](../authentication/how-to-mfa-number-match.md)|Feature change|May 8, 2023|
 |[Azure AD Domain Services virtual network deployments](../../active-directory-domain-services/overview.md)|Retirement|Mar 1, 2023|
 |[License management API, PowerShell](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/migrate-your-apps-to-access-the-license-managements-apis-from/ba-p/2464366)|Retirement|*Mar 31, 2023|
 

articles/active-directory/develop/custom-rbac-for-developers.md

@@ -3,13 +3,13 @@ title: Manage the lifecycle of group-based licenses in Azure AD
 description: This step-by-step tutorial shows how to create an access package for managing group-based licenses in entitlement management.
 services: active-directory
 documentationCenter: ''
-author: sama
+author: owinfreyATL
 ms.service: active-directory
 ms.workload: identity
 ms.tgt_pltfrm: na
 ms.topic: tutorial
 ms.subservice: compliance
-ms.date: 01/25/2023
+ms.date: 05/25/2023
 ms.author: owinfrey
 ms.collection: M365-identity-device-management
 
@@ -60,7 +60,7 @@ For more information, see [License requirements](entitlement-management-overview
 
 1. Select **Next: Requests** to go to the **Requests** tab.
 
-   On this tab, you create a request policy. A *policy* defines the rules for access to an access package. You'll create a policy that allows employees in the resource directory to request the access package.
+   On this tab, you create a request policy. A *policy* defines the rules for access to an access package. You create a policy that allows employees in the resource directory to request the access package.
 
 3. In the **Users who can request access** section, select **For users in your directory** and then select **All members (excluding guests)**. These settings make it so that only members of your directory can request Office licenses.
 
@@ -90,16 +90,16 @@ For more information, see [License requirements](entitlement-management-overview
 
 2. In the **Expiration** section, for **Access package assignments expire**, select **Number of days**.
 
-3. In **Assignments expire after**, enter **365**. This box specifies when members who have access to the access package will need to renew their access. 
+3. In **Assignments expire after**, enter **365**. This box specifies when members who have access to the access package needs to renew their access. 
 
 4. You can also configure access reviews, which allow periodic checks of whether the employee still needs access to the access package. A review can be a self-review performed by the employee. Or you can set the employee's manager or another person as the reviewer. For more information, see [Access reviews](entitlement-management-access-reviews-create.md). 
 
     In this scenario, you want all employees to review whether they still need a license for Office each year.
 
     1. Under **Require access reviews**, select **Yes**.
-    2. You can leave **Starting on** set to the current date. This date is when the access review will start. After you create an access review, you can't update its start date.
-    3. Under **Review frequency**, select **Annually**, because the review will occur once per year. The **Review frequency** box is where you determine how often the access review runs.
-    4. Specify a **Duration (in days)**.  The duration box is where you indicate how many days each occurrence of the access review series will run.
+    2. You can leave **Starting on** set to the current date. This date is when the access review starts. After you create an access review, you can't update its start date.
+    3. Under **Review frequency**, select **Annually**, because the review occurs once per year. The **Review frequency** box is where you determine how often the access review runs.
+    4. Specify a **Duration (in days)**.  The duration box is where you indicate how many days each occurrence of the access review series runs.
     5. Under **Reviewers**, select **Manager**.
 
 ## Step 6: Review and create your access package