请求指导：实现Azure AD等效于ADFS的主动认证方法

Hey there! Let's break down how to replicate your ADFS-based Active Authentication flow in Azure AD. Your original setup uses the WS-Trust UsernameMixed endpoint to fetch a SAML token via a SOAP request—Azure AD leans on OAuth 2.0/OpenID Connect instead, and the closest equivalent flow here is the Resource Owner Password Credentials (ROPC) grant. Here's how to implement it step by step:

Step 1: Set Up Your Azure AD Application Registration #

First, you need to configure an app in Azure AD to support this flow:

• Head to the Azure Portal > Azure Active Directory > App Registrations > New Registration.
• After creating the app, go to Authentication > Under Advanced settings, toggle on Allow public client flows (ROPC is classified as a public client flow).
• Navigate to API Permissions > Add the permissions your app needs to access the target resource (e.g., Microsoft Graph permissions, or custom API permissions) and grant admin consent if required (for tenant-wide access).

Step 2: Equivalent cURL Command for Azure AD #

Instead of the SOAP request to your ADFS endpoint, you'll call Azure AD's token endpoint with a form-encoded request. Here's the working cURL command:

curl https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token \
  -d "client_id={your-client-id}" \
  -d "scope={space-separated-scopes}" \
  -d "username={user-upn}" \
  -d "password={user-password}" \
  -d "grant_type=password" \
  --verbose -o "output.txt"

Parameter Breakdown: #

• {tenant-id}: Your Azure AD tenant identifier (can be your tenant domain like contoso.onmicrosoft.com or the tenant's GUID).
• {your-client-id}: The Application (client) ID from your Azure AD app registration overview page.
• {space-separated-scopes}: A list of scopes for the resource you want to access (e.g., https://graph.microsoft.com/User.Read for Microsoft Graph, or api://{custom-api-client-id}/access_as_user for a custom API). For a bearer token targeting a specific app, use the resource URI as a scope.
• {user-upn}: The user's User Principal Name (usually their email address associated with Azure AD).
• {user-password}: The user's Azure AD account password.

Key Context & Comparisons to Your ADFS Setup #

• Token Format: By default, Azure AD returns a JWT (JSON Web Token) instead of a SAML token. If you specifically need a SAML token, you can use Azure AD's SAML endpoint, but the ROPC flow is the standard equivalent for direct username/password authentication.
• Security Caveats: ROPC is not recommended for most production scenarios. It exposes user passwords directly in the request, and it doesn't support multi-factor authentication (MFA)—if your tenant enforces MFA, this flow will fail. Azure AD strongly recommends using interactive flows (like the Authorization Code flow) whenever possible for better security.
• Mapping to Your Original ADFS Request:
  • The UsernameToken section in your request.txt maps directly to the username and password parameters in the Azure AD request.
  • The AppliesTo endpoint in your ADFS SOAP body corresponds to the scope parameter (target resource URI) in the Azure AD token request.

Alternative: Fetching a SAML Token (If Required) #

If you must replicate the SAML token output from your ADFS setup, you'll need to use Azure AD's SAML assertion endpoint with a username/password flow. This is less straightforward than ROPC, so we recommend sticking with ROPC unless you have a hard requirement for SAML.

内容的提问来源于stack exchange，提问作者Jatin Dhoot