Azure App Service's built-in authentication and authorization feature, often called "Easy Auth," provides two primary methods to access authenticated user information. For server-side code, the App Service platform injects user claims directly into the HTTP request headers, such as X-MS-CLIENT-PRINCIPAL-NAME and X-MS-CLIENT-PRINCIPAL. For client-side code (e.g., a single-page application), a GET request can be made to the special /.auth/me endpoint. This endpoint returns a JSON object containing all the claims for the currently logged-in user, which the client can then parse and use.

B. environment variables: Environment variables store application settings and secrets, which are static for the app instance, not dynamic per-user information for each request.

D. /.auth/login endpoint: The /.auth/login/ endpoint is used to initiate the authentication flow with a specific identity provider, not to retrieve details about an already authenticated user.

1. Microsoft Docs, "Authentication and authorization in Azure App Service and Azure Functions", Section: "Access user claims". This section explicitly states: "For all language frameworks, App Service makes the claims in the incoming token available to your code by injecting them into the request headers." It details the specific headers, including X-MS-CLIENT-PRINCIPAL, which validates option A.

2. Microsoft Docs, "Authentication and authorization in Azure App Service and Azure Functions", Section: "Retrieve user claims in code". This section describes the client-directed flow: "From client-side code, the client can send an HTTP GET request to the /.auth/me endpoint to get the user claims." This validates option C.

3. Microsoft Docs, "Authentication and authorization in Azure App Service and Azure Functions", Section: "Authentication flow". This section describes the purpose of the login endpoint: "The client app can then redirect the user to /.auth/login/ to sign in." This confirms that the /.auth/login endpoint is for initiating login, making option D incorrect.