Microsoft Entra package v1.0.0

The value stored under this reference is the complete Authorization header value (scheme included): the scheme 'Bearer', one separating space, then an OAuth2 access token for Microsoft Graph — 'Bearer <token>'. For the client-credentials flow the token is minted by an external token process from the client's own app registration against login.microsoftonline.com — POST /{tenant}/oauth2/v2.0/token with scope https://graph.microsoft.com/.default — and placed in the client's own secret manager by that external process; this grant issues no refresh token, so there is no refresh path to review, and renewal ownership sits with the external process, which obtains a replacement access token before the current one expires (access tokens last about an hour) and stores the new complete header value. A delegated user-consent token is equally valid for these reads and acts as the signed-in user; the deployment chooses the flow, and the executor injects the stored value verbatim and performs no token lifecycle itself.

The stored value is never the client secret or certificate assertion material — those stay with the external token process, and a certificate credential is preferable to a client secret for the app registration. Distinguish the three revocation effects: rolling or removing the app registration's credentials shuts down future token issuance; removing the app's granted permissions or revoking the user's grant removes authorization for new tokens; neither invalidates an already-issued access token — Microsoft documents access tokens as valid until their own expiry (a default lifetime varying between 60 and 90 minutes, 75 on average), so plan any emergency revocation around that remaining-validity window.

An expired value fails closed.

Least privilege: with application permissions, consent only the read set named in the pack notes (User.Read.All, GroupMember.Read.All for groups, GroupMember.ReadBasic.All for group members, RoleManagement.Read.Directory, Application.Read.All) and no write or Directory.ReadWrite.* scope. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

GROUP_ID in the group-members endpoint path is a placeholder: the deployment must substitute the concrete group each capability is bound to before enabling the pack, and the pack must not be enabled with the literal in place — the review does not rely on Microsoft Graph rejecting a literal placeholder identifier as the control, and allowlisting graph.microsoft.com does not make an unsubstituted pack safe. The egress allowlist stays graph.microsoft.com, a real shared API host, not a placeholder.

This pack is deliberately distinct from the Microsoft 365 package, which owns mail, calendar and Teams: this pack registers only Entra directory reads, and no capability id or resource id overlaps. This pack registers only endpoints the official Microsoft Graph v1.0 documentation publishes: list users, list groups, list a group's direct members, list activated directory roles, and list applications (app registrations).

Two documented behaviours a reviewer must know: directoryRoles returns only roles activated in the tenant — a role that has never been activated is absent from the collection, so absence from the read is not evidence of absence of the role template (directoryRoleTemplates is not registered); and the v1.0 list-members API has a Microsoft-documented known issue in which service principals are not listed as group members, so the membership read is not a complete statement of service-principal membership.

All five capabilities are reads at the minimum R0 tier; users and group memberships register at the pii class because display names, mail addresses, phone numbers and member identities are personal data.

Documented exclusions, pending a dedicated identity-write review because membership- and privilege-changing writes are broad-impact: this pack does not register user creation (POST /users), user update or deletion (PATCH/DELETE /users/{id}), account enable/disable or password operations, group creation, update or deletion, group membership changes (POST/DELETE /groups/{id}/members/$ref and owners), directory role activation or role assignment, administrative-unit membership changes, and application or servicePrincipal creation, update, deletion, credential or permission-grant operations, and no write capability ships in this pack at all.

Use an app registration whose Microsoft Graph permissions cover only what these reads need; the pack does not create one. Least-privileged application permissions per the dated permission tables in the referenced operation documentation: User.Read.All for list users, GroupMember.Read.All for list groups, GroupMember.ReadBasic.All (basic member information only) for list group members — the least-privileged permission the dated members permission table names — RoleManagement.Read.Directory for directory roles, and Application.Read.All for app registrations.

The broader Group.Read.All is not least-privileged for either group operation and is not recommended here. One documentation anomaly flagged for re-review: the dated list-groups page's permission table currently shows the newer, write-scoped Group-NestingSupport.ReadWrite.All entry in its least-privileged cell, with GroupMember.Read.All among the read permissions the table names for the operation; this pack consents the read-scoped permission. Application permissions are tenant-wide daemon-grade power consented by an admin, while delegated permissions act as one signed-in user within that user's own access — the choice is the deployment's.

Documentation review is complete, with dated operation, permission, and token-lifecycle sources listed in the review record on this page. Library review does not establish tenant connectivity or executor operation; those remain deployment checks.