> ## Documentation Index
> Fetch the complete documentation index at: https://developers.pleo.io/llms.txt
> Use this file to discover all available pages before exploring further.

# PKCE and Secured Patterns

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.

<Note>
  HTTP is permitted only for `localhost` redirect URIs in development environments.
</Note>

## 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.

## Related Reading

* [Token Lifecycle](/docs/current/integration-design/auth/oauth/token-lifecycle/integration-design-auth-oauth-token-overview)
* [Client Configuration](/docs/current/integration-design/auth/oauth/getting-set-up/oauth-client-configuration)
* [OAuth 2.0 Setup Workflow Guide](/docs/current/guides/oauth-workflow-guide)