# Authentication Your application can authenticate with our API using two different methods. Both options can be configured directly in the app under: **Settings → Apps & API** ## 1. OAuth 2.0 Authorization Flow OAuth provides a secure and flexible authentication mechanism for applications that need delegated access on behalf of a user. We support the **Authorization Code Grant**, available in two variants: ### **1.1 Authorization Code Grant with Client Secret** Use this flow when your application can securely store a **Client Secret**, such as backend servers or confidential applications. **Key Characteristics:** * Requires *Client ID* and *Client Secret* * Uses redirect-based authorization * Suitable for server-side applications **Typical Flow:** 1. Redirect user to the OAuth authorization URL. 2. User grants access. 3. The app receives an authorization code. 4. Exchange the authorization code for an access token using the client secret. 5. Use the access token to call the API. ### **1.2 Authorization Code Grant with PKCE** For public or mobile applications that **cannot securely store a client secret**, you can use the PKCE (Proof Key for Code Exchange) variant. **Key Characteristics:** * No client secret required * Uses `code_verifier` and `code_challenge` for enhanced security * Recommended for mobile, desktop, or browser-based apps **Typical Flow:** 1. Generate a code verifier and challenge. 2. Redirect the user to the authorization URL with the PKCE challenge. 3. User grants access. 4. Receive the authorization code. 5. Exchange the authorization code for an access token using the code verifier. 6. Access the API using the token. ## 2. OAuth Endpoints The OAuth 2.0 flows use the following endpoints: ### **Authorization Endpoint** ``` https://api.kanbert.com/oauth/authorize ``` This endpoint is used to initiate the OAuth flow. It handles: * User login * The consent screen * Returning the authorization code to your redirect URL **Example (client secret or PKCE):** ``` GET https://api.kanbert.com/oauth/authorize ?response_type=code &client_id= &redirect_uri= &scope= &state= ``` ### **Token Endpoint** ``` https://api.kanbert.com/oauth/token ``` This endpoint is used to exchange the authorization code for an access token. **Example (Client Secret):** ``` POST https://api.kanbert.com/oauth/token Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code= &redirect_uri= &client_id= &client_secret= ``` **Example (PKCE):** ``` POST https://api.kanbert.com/oauth/token Content-Type: application/x-www-form-urlencoded grant_type=authorization_code &code= &redirect_uri= &client_id= &code_verifier= ``` ## 3. Direct Access Token If your integration does not require user authorization, you can generate a **direct Access Token** from the app. Ideal for: * Automated backend systems * Service-to-service communication * Scheduled or internal integrations Use the token in API requests: ``` Authorization: Bearer ``` ## Configuration Location Both OAuth credentials and direct Access Tokens can be created and managed inside the app: **Settings → Apps & API** You can: * Register new Applications * Give a name and decide wether a secret should be generated * Configure redirect URLs * Receive Client IDs and Client Secrets * Create and revoke Access Tokens