Easy tutorial on OAuth2.0 resource owner password credential flow

Introduction

I have been writing a series of blogs concentrating on oAuth 2.0 concepts and various popular grant types that are present as part of oAuth 2.0 specifications. This blog will carry forward the same task. Here I’ll cover a simple and easy tutorial on OAuth2.0 resource owner password credential flow. We use resource owner password grant flow when the client app itself exchanges resource owner’s user credential with the authorisation server. I will explicitly cover more on this a little later. Read on! 🙂

To access my previous posts on oAuth 2.0, please hit the below links –

• Understanding oAuth 2.0 concepts
• OAuth 2.0 authorization code (with refresh token) grant flow and
• OAuth 2.0 implicit grant flow.

Stakeholders in the authorisation process

• Resource Owner (user) – A user or an application who/which owns a protected resource on the Resource Server.
• Resource Server (service/API server) – It’s the server that hosts the protected resource. This data/resource is to be shared with the client/third party application.
• Client – The client or third party application requests access to the resources/data (owned by Resource Owner) stored in Resource Server
• Authorisation Server – It issues access tokens to the Client after the resource owner successfully authenticates itself and provides all the necessary authorisation.

Concepts

• Authorisation Server exposes one end point – This is used to obtain access tokens from the authorisation server.
• Client Id & Client Secret– The client must have a unique id and is called Client Id and Client Secret if client app authentication has been made mandatory by the provider organisation. In case client app authentication is not mandatory, only client id is passed.
• Access Token – To obtain the data from restricted resource, clients uses the Access Token. This has short lifetime.
• User’s credential – Resource owner’s user-id and password.

Where to use oAuth2.0 resource owner password credential flow?

We use resource owner password grant flow when the client app itself has access to resource owner’s user credential and exchanges it with the authorisation server for an access token. But wait! Isn’t oAuth framework introduced to prevent exactly this? That an client app should never have access to resource owner’s credential. Well, that’s true, oAuth took its birth to handle such scenarios!!

But still, it’s there to handle some use cases. It’s mainly used when the client app is developed/maintained by the same organisation as the authorisation server. We must NOT use this grant type when the service is going to be used by a third party app. It’s imperative that there is not a shred of mistrust between client app, authorisation server and the resource owner.

Imagine that you have account in a social media website. Now, this organisation also has a mobile app for its users. Now, when you install this app in your mobile and provide your credential to login to your own profile, you don’t panic or have second thought before providing your credential. This is because as a user you know that this is a trusted app and from the same organisation where you have your own profile.

Still in doubt or have question? Feel free to comment below.

Sequence Diagram

oAuth2-implicit-grant-flow-diagram

Flow Description

STEP 1

• If you look at the above sequence diagram, the flow starts when Resource Owner/User launches the Client App to access the its own protected resource in the Resource Server. The Resource Owner/User also provides own credential (user-id and password).

STEP 2

• The Client App then sends a request to the AUTHORISATION server  end point of with following parameters –
  • grant_type – The grant_type parameter should be set to password.
  • client_id and client_secret – This is the unique identification of the client. These two are required if the server has made client authentication mandatory. Otherwise, it’s optional to use.
  • scope – For which the Client is requesting authorisation. These are space delimited list of scope string; for example – profile, email, location etc. This is optional.
  • Username and Password – The resource owner’s user-name and password.

STEP 3

• The Authorisation sever verifies the user credential

STEP 4

• Thereafter, the Authorisation sever sends back response with –
  • token_type with value as Bearer
  • access_token with  the access token value
  • expires_in with the value indicating the life-time of the access token
  • refresh_token with the refresh token that can be used to obtain new access token when the current one expires

STEP 5

• Client app then uses the access token to hit the protected resource URL and accesses the protected data.
• When the access token expires, client app can use the refresh token to request new access token.

Conclusion

Well, that’s how simple it is. Please let me know if you have any further question on the explanation so far. Following are some of the references that I have used for my own learning process.

• https://alexbilbie.com/guide-to-oauth-2-grants/
• https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.1/com.ibm.isam.doc/config/concept/con_oauth20_workflow.html