OAuth 2.0 describes a number of grant types to authenticate an API endpoint request. The term “grant type” refers to the way an application gets an access token(a long string of characters that serves as a credential used to access protected resources).
If you are unaware of OAuth 2.0. Please read the blog: Introduction to OAuth 2.0.
There are four main grant types which Apigee Edge supports:
- Client Credentials (used with Applications API access)
- Authorization Code (used with server-side Applications)
- Implicit Grant (used with Mobile Apps or Web Applications)
- Resource Owner Password Credentials (used with trusted Applications, such as those owned by the service itself)
Each grant type is optimized for a particular use case, whether that’s a web app, a native app, a device without the ability to launch a web browser or server-to-server applications.
Let’s discuss each grant type one by one:
Client Credentials
- This grant type is useful when the app needs to access backend data storage service.
- The flow is strictly between a client application and an authorization server, the end user doesn’t participate in this flow (For information on the Authorization server, please read The Oauth 2.0 Flow).
- This type is only used with the confidential client, clientID and secret are used as username and password.
- This is the least secure and there is no user context.
- Example: Can be internal Cron jobs or batch jobs.
- Few actors involved in this flow:
- Client Application
- Authorization Server
- Resource Server
Authorization Code
- This grant type is used with confidential clients or clients that can securely store clientID and secret.
- The main reason to use this grant type: If there is a client application that wants access to a third party resource server and you don’t want to share user’s credentials with the client application.
- So, use when the app resides on the server rather than the client. Also, called Three-legged Oauth.
- Example: Sign in with facebook button or any other provider button to log in to third-party applications.
- Actors involved in this flow:
- User
- User Agent
- Client
- Apigee Authorization server
- Authentication Server
- Resource Server
Implicit Grant
- This grant type is typically used with browser-based clients.
- The main reason to use this grant type: If there’s a client application that wants access to a third party resource owner.
- So, this is the simplified version of authorization code grant type where the authorization code is not sent back directly instead accessToken is sent back.
- Additionally, you don’t want to share the user’s credential with a client application.
- Example: Single page UI only applications
- Actors involved in this flow:
- User
- Browser
- Client application
- Authorization server
- Authentication Server
- Resource Server
Resource Owner Password Credentials
- This grant type is used when resources are owned by a particular user and the requesting application is trusted.
- Username and password can be directly used as an authorization grant to obtain an access token.
- Generally, these applications are written by the same company where you can take username and password to authenticate the user and generate an access token which will be used in subsequent calls.
- So, credentials should only be used when there is a high degree of trust between the resource owner and the client.
- This grant type generates refresh token along with access token.
- Actors involved in this flow:
- User
- Client
- Authorization Server
- Resource Server
Conclusion
You should now have a good idea of how OAuth 2 grant type works, and when a particular authorization flow should be used.
If you want to learn more about OAuth 2 grant type, check out these valuable resources:
