Search code examples
javawso2-api-managerwso2-identity-serverwso2-esb

Difference between grant_type=client_credentials and grant_type=password in Authentication Flow?


I would like to understand the difference between grant_type=client_credentials and grant_type=password in Authentication or in OAuth2 Flow concept.

I am following below sites:

I presume grant_type=password is not secure way as far as using grant_type in JavaScript development. But I still wonder if someone can help me to understand this concept.

I also observed that grant_type=client_credentials doesn't provide "refresh_token", it only provides access_token where as grant_type=password provides both access_token and refresh_token.

Hoping to get detailed explanation. I am using WSO2 API Manager for OAuth2 for my application development


Solution

  • Resource owner credentials grant (password grant type)

    When this grant is implemented the client itself will ask the user for their username and password (as opposed to being redirected to an IdP authorisation server to authenticate) and then send these to the authorisation server along with the client’s own credentials. If the authentication is successful then the client will be issued with an access token.

    This grant is suitable for trusted clients such as a service’s own mobile client (for example Spotify’s iOS app). You could also use this in software where it’s not easy to implement the authorisation code - for example we bolted this authorisation grant into OwnCloud so we could retrieve details about a user that we couldn’t access over LDAP from the university’s Active Directory server.

    Client credentials grant

    This grant is similar to the resource owner credentials grant except only the client’s credentials are used to authenticate a request for an access token. Again this grant should only be allowed to be used by trusted clients.

    This grant is suitable for machine-to-machine authentication, for example for use in a cron job which is performing maintenance tasks over an API. Another example would be a client making requests to an API that don’t require user’s permission.

    When someone visits a member of staff’s page on the University of Lincoln staff directory the website uses its own access token (that was generated using this grant) to authenticate a request to the API server to get the data about the member of staff that is used to build the page. When a member of staff signs in to update their profile however their own access token is used to retrieve and update their data. Therefore there is a good separation of concerns and we can easily restrict permissions that each type of access token has.