Skip to main content
OAuth 2.0 integrations with Pleo must follow established security patterns to protect users, credentials, and tokens throughout the authorisation lifecycle. This page explains why these patterns exist and when they apply. Detailed configuration and implementation guidance is covered in the linked pages.

​
Proof Key for Code Exchange (PKCE)

PKCE (Proof Key for Code Exchange) protects authorisation code flows from interception and replay attacks. It is particularly important for public clients, where a client secret cannot be kept confidential.

​
When PKCE Is Required

  • Mandatory for public clients:
    • Single Page Applications (SPAs)
    • Mobile applications
  • Strongly recommended for all OAuth 2.0 clients where supported
Only the S256 code challenge method is supported. The plain method is not allowed. PKCE is configured as part of your OAuth 2.0 client setup and handled automatically by most standards-compliant OAuth 2.0 libraries. See Client Configuration and OAuth 2.0 Libraries and Standards for details.

​
Secure Transport (HTTPS)

All OAuth 2.0-related communication must occur over HTTPS, including:
  • Authorisation requests
  • Token exchanges
  • Token refresh requests
  • API calls using access tokens
Using HTTPS prevents interception of authorisation codes and tokens in transit.
HTTP is permitted only for localhost redirect URIs in development environments.

​
Client Classification and Responsibilities

OAuth 2.0 security requirements vary depending on client type:
  • Public clients
    Cannot safely store a client secret. Must rely on PKCE and secure redirect handling.
  • Confidential clients
    Can securely store a client secret and must authenticate at the token endpoint using client_secret_basic.
Understanding your client type is essential before implementing OAuth 2.0 flows. This distinction is covered in the OAuth 2.0 Authentication Workflow.

​
Avoiding Common Security Pitfalls

Integrations should avoid the following anti-patterns:
  • Implementing OAuth 2.0 flows manually instead of using a standard library
  • Storing tokens in insecure locations (for example, browser local storage)
  • Reusing expired or replaced refresh tokens
  • Skipping PKCE for public clients
  • Hardcoding secrets in frontend or distributed code
Correct token handling and storage are covered in the Token Lifecycle section.