Microsoft identity platform and OAuth 2.0 Resource Owner Password Credentials
The Microsoft identity platform supports the OAuth 2.0 Resource Owner Password Credentials (ROPC) grant, which allows an application to sign in the user by directly handling their password. This article describes how to program directly against the protocol in your application. When possible, we recommend you use the supported Microsoft Authentication Libraries (MSAL) instead to acquire tokens and call secured web APIs. Also take a look at the sample apps that use MSAL.
Warning
Microsoft recommends you do not use the ROPC flow. In most scenarios, more secure alternatives are available and recommended. This flow requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows aren't viable.
Important
- The Microsoft identity platform only supports the ROPC grant within Microsoft Entra tenants. This means that you must use a tenant-specific endpoint (
https://login.partner.microsoftonline.cn/{TenantId_or_Name}
) or theorganizations
endpoint. - Accounts that don't have passwords can't sign in with ROPC, which means features like SMS sign-in, FIDO, and the Authenticator app won't work with that flow. If your app or users require these features, use a grant type other than ROPC.
- If users need to use multi-factor authentication (MFA) to log in to the application, they will be blocked instead.
- ROPC is not supported in hybrid identity federation scenarios (for example, Microsoft Entra ID and ADFS used to authenticate on-premises accounts). If users are full-page redirected to an on-premises identity provider, Microsoft Entra ID is not able to test the username and password against that identity provider.
- An exception to a hybrid identity federation scenario would be the following: Home Realm Discovery policy with AllowCloudPasswordValidation set to TRUE will enable ROPC flow to work for federated users when an on-premises password is synced to the cloud. For more information, see Enable direct ROPC authentication of federated users for legacy applications.
- Passwords with leading or trailing whitespaces are not supported by the ROPC flow.
Protocol diagram
The following diagram shows the ROPC flow.
Authorization request
The ROPC flow is a single request; it sends the client identification and user's credentials to the identity provider, and receives tokens in return. The client must request the user's email address (UPN) and password before doing so. Immediately after a successful request, the client should securely discard the user's credentials from memory. It must never save them.
// Line breaks and spaces are for legibility only. This is a public client, so no secret is required.
POST {tenant}/oauth2/v2.0/token
Host: login.partner.microsoftonline.cn
Content-Type: application/x-www-form-urlencoded
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=user.read%20openid%20profile%20offline_access
&username=MyUsername@myTenant.com
&password=SuperS3cret
&grant_type=password
Parameter | Condition | Description |
---|---|---|
tenant |
Required | The directory tenant that you want to log the user into. The tenant can be in GUID or friendly name format. However, its parameter can't be set to common or consumers , but may be set to organizations . |
client_id |
Required | The Application (client) ID that the Microsoft Entra admin center - App registrations page assigned to your app. |
grant_type |
Required | Must be set to password . |
username |
Required | The user's email address. |
password |
Required | The user's password. |
scope |
Recommended | A space-separated list of scopes, or permissions, that the app requires. In an interactive flow, the admin or the user must consent to these scopes ahead of time. |
client_secret |
Sometimes required | If your app is a public client, then the client_secret or client_assertion can't be included. If the app is a confidential client, then it must be included. |
client_assertion |
Sometimes required | A different form of client_secret , generated using a certificate. For more information, see certificate credentials. |
Successful authentication response
The following example shows a successful token response:
{
"token_type": "Bearer",
"scope": "User.Read profile openid email",
"expires_in": 3599,
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
"id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}
Parameter | Format | Description |
---|---|---|
token_type |
String | Always set to Bearer . |
scope |
Space separated strings | If an access token was returned, this parameter lists the scopes the access token is valid for. |
expires_in |
int | Number of seconds that the included access token is valid for. |
access_token |
Opaque string | Issued for the scopes that were requested. |
id_token |
JWT | Issued if the original scope parameter included the openid scope. |
refresh_token |
Opaque string | Issued if the original scope parameter included offline_access . |
You can use the refresh token to acquire new access tokens and refresh tokens using the same flow described in the OAuth Code flow documentation.
Warning
Don't attempt to validate or read tokens for any API you don't own, including the tokens in this example, in your code. Tokens for Microsoft services can use a special format that will not validate as a JWT, and may also be encrypted for consumer (Microsoft account) users. While reading tokens is a useful debugging and learning tool, do not take dependencies on this in your code or assume specifics about tokens that aren't for an API you control.
Error response
If the user hasn't provided the correct username or password, or the client hasn't received the requested consent, authentication will fail.
Error | Description | Client action |
---|---|---|
invalid_grant |
The authentication failed | The credentials were incorrect or the client doesn't have consent for the requested scopes. If the scopes aren't granted, a consent_required error will be returned. To resolve this error, the client should send the user to an interactive prompt using a webview or browser. |
invalid_request |
The request was improperly constructed | The grant type isn't supported on the /common or /consumers authentication contexts. Use /organizations or a tenant ID instead. |
Learn more
For an example implementation of the ROPC flow, see the .NET console application code sample on GitHub.