Authentication Methods
- PKCE Only
- Client Secret Only
- PKCE + Client Secret
Best for: Public clients (SPAs, mobile apps) where secrets cannot be securely stored.
How it Works
- Uses Proof Key for Code Exchange (PKCE) for security
- Default method for public clients
- Code verifier/challenge mechanism provides security
- No client secret required or used
Security Benefits
- ✅ No sensitive credentials to manage client-side
- ✅ Dynamic verification for each authentication request
- ✅ Industry standard for public clients
- ✅ Prevents authorization code interception attacks
Configuration
When to Use Each Method
PKCE Only
- Single-page applications (SPAs)
- Mobile applications
- Frontend applications (React, Vue, Angular)
- When client secrets cannot be securely stored
- Default for public clients
Client Secret Only
- Legacy OAuth 2.0 integrations
- Traditional server-side applications
- When PKCE is not supported
- Simple backend services
- Existing OAuth infrastructure
PKCE + Client Secret
- High-security server applications
- Financial or healthcare systems
- Enterprise backend services
- Maximum security requirements
- Modern confidential clients
Getting Client Secrets
To generate a client secret, log into your dashboard at auth.civic.com, navigate to the Security tab, and click “Generate Client Secret”. Important: The client secret is only displayed once upon generation, so make sure to copy and securely store it immediately. You can always regenerate a new client secret if needed.

Security Requirements: Client secrets must be stored securely and never exposed in client-side code. They are suitable only for server-side applications with secure credential storage.
Flexible Security: Choose the authentication method that best fits your application architecture. Use PKCE-only for public clients, client secrets for traditional OAuth compatibility, or both together for maximum security.
Security Considerations
PKCE Security Model
PKCE Security Model
- No secrets to compromise: Even if your frontend code is inspected, there are no sensitive credentials
- Dynamic verification: Each authentication request uses a unique code verifier/challenge pair
- Domain validation: Production apps require domain registration for additional security
- Industry standard: Recommended by OAuth 2.0 Security Best Practices
Client Secret Security Model
Client Secret Security Model
- Secure storage required: Client secrets must be stored securely and never exposed to client-side code
- Server-side only: Authentication logic must run on your backend servers
- Environment variables: Use environment variables or secure secret management systems
- HTTPS required: Always use HTTPS in production to protect credentials in transit
Implementation Example
The Civic Auth SDK is initialized with aconfig
object that varies based on the authentication method you choose. The core implementation remains the same.
Configuration Parameters
Parameter | PKCE Only (Default) | Client Secret Only | PKCE + Client Secret (Max Security) | Notes |
---|---|---|---|---|
clientId | Required | Required | Required | Your application’s Client ID. |
clientSecret | Not used | Required | Required | Generate in dashboard Security tab. |
pkce | true (default) | false | true | Enables or disables PKCE. |
redirectUrl | Required | Required | Required | The URL to redirect to after login. |
postLogoutRedirectUrl | Optional | Optional | Optional | The URL to redirect to after logout. |
For full implementation examples with specific frameworks, see our integration guides. The guides show the PKCE-only approach by default, but you can adapt the
config
object using the parameters above for other flows.