Resource Owner Credentials

• Resource Owner (User) provides the Client a plain username and password which the Client then uses with the Authorization Server.

• Based on the "ask for the keys" antipattern and pretty much goes against what OAuth was intended for.

• Should only be used in cases to bridge clients into the OAuth World that otherwise would be dealing with username/password.

• Still has some security benefits compared to the traditional approach, such as:

  • Protected Resource no longer needs to know or see the user's password (as it only deals with OAuth tokens)

  • Client Application no longer needs to store the passwords and transmit them to the resource servers.

Flow In Action

1. The user inputs their credentials into the Client.

2. The Client replays the credentials in a back-channel request to the Authorization Server.

3. The Authorization Server validates the credentials and returns an access token to the Client.

4. The Client can use the access token with the Resource Provider to access protected resources.