OAuth 2.0 Authorization Flow

OAuth 2.0 allows applications to authenticate users and access protected resources without storing passwords. The process involves obtaining an initial access token interactively via a browser and then refreshing it non-interactively to maintain access.

Note: If the provider supports the Client Credentials flow, then it may be better to obtain the access token in that way.

Interactive Authorization (Initial Access Token)

The initial OAuth 2.0 access token is obtained through user interaction in a browser. This typically follows the Authorization Code Flow:

1. User Redirected to Authorization Server
  • The application redirects the user to the authorization server’s URL, requesting authorization (interactively in a browser).
  • If using Chilkat.OAuth2 in a desktop application or script (not in a web application), this is accomplished by first calling Chilkat.OAuth2.StartAuth to get the URL, and then call Chilkat.OAuth2.LaunchBrowser to redirect the user to the authorization server's URL.
2. User Logs In and Grants Permission
  • (in the launched browser) The user authenticates using their credentials.
  • The authorization server presents a consent screen, asking the user to approve access.
3. Authorization Code is Returned and OAuth Server Responds with Access & Refresh Tokens
  • The server redirects back to the app’s redirect URI with an authorization code, or with a status indicating the access was denied.
  • If using Chilkat:  When StartAuth was called, Chilkat launched a background thread to listen for the browser redirect. Once the response is received, OAuth2.AuthFlowState updates with the result (success or failure), and the response is stored in OAuth2.AccessTokenResponse.
4.  Sample Response: 
{
"access_token": "ACCESS_TOKEN",
"expires_in": 3600,
"refresh_token": "REFRESH_TOKEN",
"token_type": "Bearer"
}
The access token is used for API calls. The refresh token allows renewing the access token without user interaction.

Non-Interactive Token Refresh

After the initial token expires, the application automatically obtains a new access token using the refresh token, without user interaction.

1. App Sends a Token Refresh Request
  • When the access token expires, the application sends a request to refresh it.
  • If using Chilkat, the following POST is sent by calling Chilkat.OAuth.RefreshAccessToken. 
POST https://authorization-server.com/oauth/token
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&refresh_token=REFRESH_TOKEN
&client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET
2. OAuth Server Responds with a New Access Token 
{
"access_token": "NEW_ACCESS_TOKEN",
"expires_in": 3600,
"refresh_token": "NEW_REFRESH_TOKEN",
"token_type": "Bearer"
}
The new access token replaces the old one. Some providers rotate refresh tokens, returning a new refresh token.

Key Concepts

  • Access Token: Short-lived token used to access APIs (e.g., expires in 1 hour).
  • Refresh Token: Long-lived token used to get new access tokens without user interaction.
  • Token Expiration: Access tokens expire; refresh tokens may also have limits (e.g., 30 days).

Security Considerations

  • Keep the refresh token secure (store it securely and never expose it in front-end code).
  • Refresh token expiry varies by provider (some expire after 30–90 days).
  • Use token rotation if the OAuth2 provider supports it.