!!! Overview
[{$pagename}] ([ROPC]) [Grant Type] may be used directly as an [Authorization Grant] to obtain an [Access Token].

%%error
[{$pagename}] [MUST NOT] be used. This grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, this results in an increased attack surface (credentials can leak in more places than just the AS) and users are trained to enter their credentials in places other than the AS.

Furthermore, adapting the resource owner password credentials grant to two-factor authentication, authentication with cryptographic credentials, and authentication processes that require multiple steps can be hard or impossible (WebCrypto, WebAuthn).

[OAuth 2.0 Security Best Current Practice] section 3.4. Resource Owner Password Credentials Grant
%%
[{$pagename}] is intended for applications for which no other [Grant Type] works, as it requires your [application] code to be __fully trusted and protected from credential-stealing attacks__. [{$pagename}] is made available primarily to provide a consistent and predictable integration pattern for legacy applications which can't otherwise be updated to a more secure flow such as Authorization Code Flow. This should be your last option, not your first choice.

At a high-level, this flow has the following steps:
* Your [OAuth Client] [application] collects a user's [credentials].
* Your [OAuth Client] sends these [OAuth Client] to the [Authorization Server].
* If the credentials are accurate, [Authorization Server] responds with the [Access Token]. 

The [credentials] should only be used when there is a high degree of [trust] between the [Resource Owner] and the [OAuth Client] (e.g., the client is part of the device operating system or a highly privileged application), and when other authorization [Grant Types] are not  available.

Some [{$pagename}] [Authorization Server] may also return a [Refresh Token]

Even though this [Grant Type] requires direct [OAuth Client] access to the [Resource Owner] [credentials], the [Resource Owner] credentials are used for a single request and are exchanged for an [Access Token].  This [Grant Type] can eliminate the need for the client to store the [Resource Owner] credentials for future use, by exchanging the credentials with a long-lived [Access Token] or [Refresh Token].[1]

[{$pagename}] is typically used to convert legacy systems to [OAuth 2.0] and no more secure than [Basic Authentication Scheme].%%warning
[{$pagename}] is intended to be used when no other [Grant Types] are available and ONLY when there is a high degree of [trust] between the [Resource Owner] and the [OAuth Client]
.%%
!! Features
* Convenient token renewal since a [Refresh Token] is provided
* Simple one-call is necessary to obtain [Access Token] and [Refresh Token]
* [{$pagename}] exercises the [Password Anti-Pattern] which is Reduced Security

!! [Token_endpoint]
The [OAuth Client] sends the request to the [token_endpoint] of the [Authorization Server] and includes:
* using a [base64]-encoded value of [client_id]:[Client Secret] in the [Authorization Header]
* the [Resource Owner] [credentials] are sent as form parameters names of "username" and "password"
* [grant_type]=password as a form parameter.
* [HTTP POST]
A successful response is with [Access Token] and [Refresh Token].!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [RFC 6749 Resource Owner Password Credentials|https://tools.ietf.org/html/rfc6749#section-1.3.3|target='_blank'] - based on data observed:2015-05-18
* [#2] - [Microsoft identity platform and the OAuth 2.0 resource owner password credential|https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc|target='_blank'] - based on information obtained 2019-07-26 
* [#3] - [Resource Owner Password Flow|https://developer.okta.com/docs/guides/implement-password/overview/|target='_blank'] - based on information obtained 2019-07-26