Update access-tokens.md

will-bartlett · web-flow · commit df9f14971986 · 2023-07-13T14:47:15.000-07:00
diff --git a/articles/active-directory/develop/access-tokens.md b/articles/active-directory/develop/access-tokens.md
@@ -110,10 +110,13 @@ Azure AD makes available a tenant-independent version of the document at [https:
       ]
     }
     ```
- 3. Applications that use Azure AD's tenant-id (`tid`) claim as a trust boundary instead of the standard issuer claim should ensure that the tenant-id claim is a guid and that the issuer and tenant-id match.
+ 3. Applications that use Azure AD's tenantid (`tid`) claim as a trust boundary instead of the standard issuer claim should ensure that the tenant-id claim is a guid and that the issuer and tenantid match.
 
 Using tenant-independent metadata is more efficient for applications which accept tokens from many tenants.
 
+> [!NOTE]
+> With Azure AD tenant-independent metadata, claims should be interpreted within the tenant, just as under standard OpenID Connect, claims are interpreted within the issuer. That is, `{"sub":"ABC123","iss":"https://login.microsoftonline.com/8eaef023-2b34-4da1-9baa-8bc8c9d6a490/v2.0","tid":"8eaef023-2b34-4da1-9baa-8bc8c9d6a490"}` and `{"sub":"ABC123","iss":"https://login.microsoftonline.com/82229342-1101-4ab6-817b-70c0747630f3/v2.0","tid":"82229342-1101-4ab6-817b-70c0747630f3"}` describe different users, even though the `sub` is the same, because claims like `sub` are interpreted within the context of the issuer/tenant.
+
 ### Validate the signature
 
 A JWT contains three segments separated by the `.` character. The first segment is the **header**, the second is the **body**, and the third is the **signature**. Use the signature segment to evaluate the authenticity of the token.

Original file line number	Diff line number	Diff line change
`@@ -110,10 +110,13 @@ Azure AD makes available a tenant-independent version of the document at [https:`
`110`	`110`	`]`
`111`	`111`	`}`
`112`	`112`	```
`113`		- 3. Applications that use Azure AD's tenant-id (`tid`) claim as a trust boundary instead of the standard issuer claim should ensure that the tenant-id claim is a guid and that the issuer and tenant-id match.
	`113`	+ 3. Applications that use Azure AD's tenantid (`tid`) claim as a trust boundary instead of the standard issuer claim should ensure that the tenant-id claim is a guid and that the issuer and tenantid match.
`114`	`114`
`115`	`115`	`Using tenant-independent metadata is more efficient for applications which accept tokens from many tenants.`
`116`	`116`
	`117`	`+> [!NOTE]`
	`118`	+> With Azure AD tenant-independent metadata, claims should be interpreted within the tenant, just as under standard OpenID Connect, claims are interpreted within the issuer. That is, `{"sub":"ABC123","iss":"https://login.microsoftonline.com/8eaef023-2b34-4da1-9baa-8bc8c9d6a490/v2.0","tid":"8eaef023-2b34-4da1-9baa-8bc8c9d6a490"}` and `{"sub":"ABC123","iss":"https://login.microsoftonline.com/82229342-1101-4ab6-817b-70c0747630f3/v2.0","tid":"82229342-1101-4ab6-817b-70c0747630f3"}` describe different users, even though the `sub` is the same, because claims like `sub` are interpreted within the context of the issuer/tenant.
	`119`	`+`
`117`	`120`	`### Validate the signature`
`118`	`121`
`119`	`122`	A JWT contains three segments separated by the `.` character. The first segment is the header, the second is the body, and the third is the signature. Use the signature segment to evaluate the authenticity of the token.