Overview

Candis utilizes OAuth 2.0, a widely adopted authorization framework, to allow third-party applications to securely access user data without exposing sensitive credentials. The OAuth 2.0 protocol allows the Candis User maintain control over their data while granting limited access to client applications through the use of access tokens. One of the most common flows in OAuth 2.0 is the authorization code flow.

OAuth 2.0 Authorization Code Flow

The authorization code flow is designed to handle sensitive operations securely by ensuring that access to user data is granted only after explicit user consent. The flow uses a multi-step process involving an authorization code and client secret to ensure the security of the authorization process.

Key Steps

1. Authorization Request: The client application requests authorization from the user via the Candis Authorization Server. API Reference here.
2. Authorization Code: After the user grants access, the Candis Authorization Server responds by issuing an authorization code.
3. Access Token Request: The client exchanges the authorization code for an access token by authenticating with their client secret. API Reference here
4. Access Token Use: The client can now use the access token to access the user's data in Candis.
5. Refresh Token: A refresh token may be provided for long-term access without requiring repeated user authentication. API Reference here

Key Concepts

• Client ID and Client Secret:
  The client ID uniquely identifies the client application, while the client secret is a confidential credential used by the client to authenticate itself during sensitive operations, such as exchanging the authorization code for an access token. The client secret must be stored securely, as it proves the identity of the client.
• Authorization Code:
  A short-lived code that the client application receives after the user grants authorization. The authorization code itself doesn’t provide access to resources but is exchanged for an access token in the next step.
• Access Token:
  A token that the client uses to authenticate API requests. The access token allows the client application to access the user’s protected resources on the resource server (e.g., the Candis API) without needing to handle the user’s credentials.
• Refresh Token:
  A token issued alongside the access token, which can be used to request a new access token after the original token expires. This allows long-term access without requiring the user to reauthorize the application.
• Redirect URI:
  A pre-registered URL where the authorization server sends the user after they have authenticated and authorized the client application. The redirect URI is essential to the security of the OAuth 2.0 flow, as it ensures that the authorization code is sent to the correct client. The authorization server will only send the authorization code to the registered redirect URI, preventing it from being intercepted by malicious parties. This URL must match exactly with what is pre-registered during client registration to avoid potential attacks.

📘

Credentials

To authenticate with Candis via OAuth 2.0, you’ll need the following credentials from Candis:

• Client ID: A unique identifier for your application
• Client Secret: A confidential key used to authenticate your app during the token exchange process.

Additionally, your redirect URI (the URL where the user will be redirected after authentication) must be whitelisted by Candis. Please provide Candis with your redirect URI during the client registration process to ensure proper authorization flow.

Learn more about Oauth2: https://oauth.net/2/grant-types/authorization-code/