Deprecated - InsecureID: password

Resource Owner Password Credentials Flow

Legacy flow where the end-user provides their plaintext username and password directly to the client application. Removed in OAuth 2.1 due to severe security risks.

#oauth2#password#ropc#deprecated#legacy#security-risk

Avis de sécurité : Flux déprécié

Resource Owner Password Credentials Flow is formally deprecated in modern OAuth specifications (including OAuth 2.0 Security BCP and OAuth 2.1). It poses significant security risks and must NOT be used for new applications. Use Authorization Code Flow with PKCE instead.

Présentation

The Resource Owner Password Credentials (ROPC) grant (RFC 6749 Section 4.3) was introduced as a transitional migration path for legacy client applications.

In this flow, the client application directly collects the user username and password through its own user interface, and sends those credentials in plaintext in a POST request to the token endpoint.

Why it is deprecated: Handing user credentials directly to client applications violates the core principle of OAuth (delegated authorization without sharing credentials). It exposes passwords to client-side logging, memory dumping, and malicious code. It prevents the use of Multi-Factor Authentication (MFA), Single Sign-On (SSO), and biometric passkeys, while training users to enter credentials into arbitrary third-party prompts.

OAuth 2.1 has completely removed this flow. All applications must transition to Authorization Code Flow with PKCE.

Quick Specifications

Flow Status: deprecated
Token Auth Methods: Client Secret BasicClient Secret Post
Primary Standard: RFC 6749 Section 4.3

Create Client with this Grant

Diagramme de séquence

Visual sequence illustrating entity interactions and protocol steps

Sequence Diagram

Interactive Diagram

sequenceDiagram
    autonumber
    actor U as User
    participant C as Client Application
    participant AS as Authorization Server

    U->>C: Enter username & password into client app form
    Note over C: Critical Security Risk: Client sees user's raw password!
    C->>AS: POST /oauth/token (grant_type=password, username, password, client_id, client_secret)
    AS->>AS: Validate user credentials & client authentication
    AS-->>C: 200 OK (access_token, refresh_token, token_type=Bearer)
    C-->>U: Logged in successfully

Déroulement étape par étape

Detailed breakdown of every message exchange, query parameter, and HTTP payload

User Enters Credentials into Client UI

User→Client Application

The user types their raw username and password into a form rendered directly by the client application.

Client Sends Password to Token Endpoint

Client Application→Authorization Server

The client application sends a POST request to the token endpoint with grant_type=password, transmitting the user credentials in cleartext.

ROPC Token Request

POST /oauth/token HTTP/1.1
Host: auth.example.com
Authorization: Basic bXlfY2xpZW50X2lkOm15X2NsaWVudF9zZWNyZXQ=
Content-Type: application/x-www-form-urlencoded

grant_type=password
&username=jane.doe%40example.com
&password=MySuperSecretPassword%21
&scope=read%20write

Verify Credentials and Issue Tokens

Authorization Server→Client Application

The authorization server checks the user password against its database and returns access and refresh tokens.

Token Response

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "2YotnFZFEjr1zCsicMWpAA"
}

Considérations de sécurité

Critical safeguards, threat mitigations, and implementation best practices

DEPRECATED: Removed in OAuth 2.1

The Password grant is completely removed in OAuth 2.1. It should never be used in new designs and existing deployments should be prioritized for migration to Authorization Code with PKCE.

Exposes User Passwords to Client Software

The client software gains direct knowledge of the user password, creating severe risk of password harvesting, accidental logging, and credential compromise.

Blocks Modern MFA and SSO

Because authentication happens via a non-interactive HTTP POST, users cannot be prompted for MFA challenges, FIDO2/Passkey authentication, or corporate SSO.