Skip to content
Autentico

Resource Owner Password Credentials

The Resource Owner Password Credentials (ROPC) grant allows a client to exchange a username and password directly for tokens, without going through the browser authorization flow.

Request

Section titled “Request”
Terminal window
curl -X POST https://auth.example.com/oauth2/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=password" \
  -d "username=alice" \
  -d "password=secret" \
  -d "client_id=my-client-id" \
  -d "scope=openid profile email"

Response:

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 900,
  "scope": "openid profile email"
}

Enabling for a client

Section titled “Enabling for a client”

The client must have password in its grant_types. When registering:

Terminal window
curl -X POST https://auth.example.com/oauth2/register \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "My CLI Tool",
    "redirect_uris": ["http://localhost"],
    "grant_types": ["password", "refresh_token"],
    "client_type": "public"
  }'

Limitations

Section titled “Limitations”
  • MFA is not enforced — even if mfa_enabled is true globally, the ROPC flow bypasses the MFA challenge
  • Passkey authentication is not available — ROPC only supports username/password
  • No SSO session is created — each ROPC token exchange is independent
  • Account lockout still applies — repeated failed password attempts will lock the account