OAuth, which stands for Open Authorization, is a protocol that allows users to approve applications to act on their behalf without sharing their password.
OAuth 2.0 is the most recent version and is used by most modern APIs. OAuth 2.0 is simpler to implement than OAuth 1.0 because it doesn’t require cryptographic signatures. Instead, it uses access tokens. It also provides specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.
OAuth 2.0 has several different “flows” for different types of applications:
- Authorization Code Grant (for apps running on a web server)
- Implicit Grant (for browser-based or mobile apps)
- Resource Owner Password Credentials Grant (for apps with highly trusted applications)
- Client Credentials Grant (for applications where the client is also the resource owner)
- Device Code Grant (for apps running on devices that don’t have easy access to a browser or a keyboard)
- Refresh Token Grant (for refreshing the access token)
Remember, OAuth is not the same as OpenID, which is a protocol that allows users to be authenticated. OAuth is about authorization (access control), not authentication (user identity).
Authorization Code Grant
Authorization Code Grant, also known as the “web server” flow, is commonly used when the client (application) is running on a web server. This flow allows the client to receive the access token securely. Here’s a step-by-step look at how it works:
- Authorization Request: The client (your application) redirects the user (resource owner) to the authorization server (the service you’re looking to access, like Google or Facebook). This is usually done via an HTTP redirect to an authorization endpoint, which includes query parameters like the client ID, redirect URI, response type (‘code’ for Authorization Code Grant), and scope (what access the application needs).
- User Login: The user logs into the authorization server, usually via a login form on the authorization server’s website.
3. User Consent: The authorization server prompts the user to approve or deny the client’s access request. This usually involves presenting the user with information about the application and what access it’s requesting.
4. Authorization Response: If the user approves the request, the authorization server redirects the user back to the client using the redirect URI provided earlier. The redirection URI includes an authorization code.
5. Authorization Code to Token: The client then sends a request to the token endpoint of the authorization server, including the authorization code received in the previous step, client ID, client secret, and redirect URI. These values are typically sent as form parameters.
6. Token Response: If the request from the client is valid, the authorization server sends a response containing the access token (and optionally, a refresh token) back to the client. The access token is then used by the client to access the user’s resources on the resource server (API).
7. Access Protected Resource: With the access token, the client can access the protected resources on the resource server until the token expires or is revoked.
This flow is considered to be one of the most secure because the client never exposes the user’s credentials.
What is access token?
once your application has received the access token, it will then use this token in all subsequent requests to the resource server (the server hosting the user’s data). The access token is used to authenticate these requests.
The access token is typically included in the header of the HTTP request. For example, if your application is accessing a REST API, it might include a header like this in each request:
Authorization: Bearer <access_token>
In this header, <access_token> would be replaced with the actual access token. This tells the resource server that the request comes from an application that has been granted access to the user's data.
Remember, access tokens are generally short-lived. They expire after a certain period of time for security reasons. If the access token expires, your application will need to obtain a new one. If a refresh token was provided when your application received the access token, it can use the refresh token to get a new access token without requiring the user to log in again.
Why authorization code can’t be used as access token?
The authorization code and the access token in the OAuth 2.0 flow serve different purposes and have different security considerations:
Authorization Code: This is like a one-time-use ticket that the client (your application) exchanges for an access token. It’s used in the front-channel, meaning it’s passed through the user’s web browser, so it’s potentially exposed to various threats (such as interception or token substitution). To mitigate these risks, the authorization code is short-lived and is meant to be exchanged for an access token immediately. It’s also bound to the client’s identity and can’t be used if intercepted.
Access Token: This is the “key” that the client uses to access the user’s resources. It’s issued directly from the authorization server to the client over a secure, back-channel connection, which is more secure. Access tokens are longer-lived and aren’t bound to the client’s identity in the same way as the authorization code.
By using a separate access token instead of the authorization code for accessing resources, the OAuth 2.0 flow adds an extra layer of security. If the authorization code is intercepted, it can’t be used to access resources. And because the access token is issued over a more secure channel and can be revoked by the user or the authorization server at any time, it provides more control over resource access.
What is refresh token?
A refresh token is a special kind of token that can be used to obtain a renewed access token. This is extremely useful for the fact that access tokens are usually short-lived and expire after a certain period of time, as defined by the authorization server.
Here’s how it works:
- When the access token expires, instead of asking the user to authenticate again (which would involve redirecting to the login page), the application can use the refresh token to get a new access token.
- The application sends a request to the authorization server, presenting the refresh token.
- The server validates the refresh token, and if valid, issues a new access token (and often a new refresh token).
This process is done behind the scenes and is transparent to the user, providing a smooth user experience. The use of refresh tokens allows users to remain authenticated indefinitely without needing to provide their credentials more than once, as long as they continue to use the application.
Refresh tokens are usually subject to strict storage requirements to ensure they are not leaked, as they can remain valid for a long period of time.
You can achieve API security using HTTPs, please refer this
