To implement OAuth 2.0 without exposing client secrets, the first rule is simple: never place a client secret inside JavaScript, a mobile app, a desktop app, or any code that users can inspect, extract, or decompile.
OAuth 2.0 separates applications into different client types. A traditional backend application can keep a secret because the code runs on a server controlled by the owner. A browser app or mobile app cannot keep that same secret private, so it should be treated as a public client.
The safer modern approach is to use the Authorization Code flow with PKCE, configure redirect URIs carefully, request only the scopes you need, and move sensitive token handling to a backend when the project requires stronger protection.
This guide explains the practical architecture choices, the correct flow, the common mistakes, and the security checks that help developers avoid leaking secrets while still giving users a smooth login experience.
Important security note: OAuth 2.0 mistakes can expose user accounts, access tokens, private API data, or payment-related information. For systems that handle sensitive data, use official provider documentation and consider a professional security review before going live.
Why Client Secrets Should Not Be Used in Public Apps
A client secret is only useful when it can remain confidential. If the application runs fully in a browser, mobile device, desktop app, or extension, the user can inspect the application package, network calls, source maps, compiled code, or memory. In that situation, the secret is not truly secret.
Putting a client secret inside frontend code creates a false sense of protection. Attackers do not need to break OAuth itself; they only need to copy the secret from the public app and use it elsewhere. In practice, this often appears when a developer copies backend OAuth examples into a single-page app without adapting the flow.
| Application Type | Can Keep a Client Secret? | Recommended Approach |
|---|---|---|
| Server-rendered web app | Yes, if stored only on the server | Authorization Code flow with server-side token exchange |
| Single-page app | No | Authorization Code flow with PKCE, or backend-for-frontend |
| Mobile app | No | Authorization Code flow with PKCE using the system browser |
| Desktop app | No | Authorization Code flow with PKCE and safe redirect handling |
| Machine-to-machine backend | Yes | Client Credentials flow from a protected server environment |
Use Authorization Code Flow With PKCE
PKCE, short for Proof Key for Code Exchange, protects the authorization code exchange without requiring a static client secret in the app. Instead of relying on a permanent secret, the app creates a temporary code verifier and sends a derived code challenge during the authorization request.
When the authorization server returns an authorization code, the app must prove it still has the original verifier before receiving tokens. This reduces the risk of an intercepted authorization code being exchanged by someone else.
For browser-based and native applications, this is the practical replacement for old patterns such as the Implicit flow. The Implicit flow exposes tokens directly through the browser redirect and is no longer the preferred choice for modern OAuth security.
-
Register the app as the correct client type.
Choose a public client type for browser, mobile, desktop, or extension apps. Do not register a frontend app as a confidential web server app just to receive a client secret.
-
Create a code verifier and code challenge.
Generate a high-entropy random verifier in the client. Then create a challenge, usually with SHA-256, and send the challenge in the authorization request.
-
Redirect the user to the authorization server.
Include the client ID, redirect URI, requested scopes, response type, code challenge, code challenge method, and state parameter.
-
Handle the authorization response carefully.
Validate the state value and make sure the redirect URI matches what your app expected. Do not accept random redirect responses from unknown origins.
-
Exchange the code for tokens without a client secret.
Send the authorization code and the original code verifier to the token endpoint. For a public client, the verifier replaces the need for a static secret.
-
Store and use tokens with minimal exposure.
Use short-lived access tokens, avoid unnecessary storage, and protect the app against XSS, insecure redirects, and excessive scopes.
Choose the Right Architecture Before Writing Code
The safest OAuth design depends on where your application runs and what kind of data it handles. A lightweight single-page app with low-risk API access may use Authorization Code with PKCE directly. A banking, healthcare, payment, or business dashboard should usually consider a backend layer to keep tokens away from the browser.
A backend-for-frontend pattern can be a strong option. In this model, the browser talks only to your backend using secure cookies, while the backend performs the OAuth code exchange and stores sensitive tokens server-side. This reduces token exposure in JavaScript, although it adds backend complexity.
| Architecture | Best Use Case | Main Security Care |
|---|---|---|
| Pure SPA with PKCE | Apps with moderate risk and limited scopes | Reduce token lifetime, prevent XSS, avoid localStorage when possible |
| Backend-for-frontend | Apps handling sensitive user data | Use secure, HttpOnly, SameSite cookies and CSRF protection |
| Traditional backend web app | Server-rendered apps and private dashboards | Keep secrets in server-side secret storage only |
| Native app with PKCE | Mobile and desktop applications | Use the system browser, not embedded webviews |
Implementation Checklist Before Going Live
Before launching, review the OAuth configuration as carefully as the application code. Many OAuth vulnerabilities come from small configuration mistakes, such as broad redirect URI patterns, unnecessary scopes, or accepting tokens without proper validation.
- Use Authorization Code flow with PKCE for browser and native apps.
- Do not include a client secret in frontend, mobile, desktop, or extension code.
- Register exact redirect URIs instead of broad wildcard redirects.
- Use a state parameter to protect the authorization response.
- Use nonce when OpenID Connect ID tokens are involved.
- Request only the scopes required for the feature being used.
- Keep access tokens short-lived where the provider allows it.
- Use refresh token rotation if refresh tokens are issued to public clients.
- Protect frontend apps against XSS with careful output handling and a strict Content Security Policy.
Where to Store Tokens Safely
Token storage is one of the most important decisions in an OAuth implementation. If a token is stolen, an attacker may access APIs as the user until the token expires or is revoked. The right storage choice depends on whether the app is browser-based, native, or server-side.
For browser apps, avoid storing long-lived tokens in localStorage when possible because JavaScript can read them, and XSS can expose them. Memory storage reduces persistence but may require the user to re-authenticate more often. A backend-for-frontend can store tokens on the server and issue a secure session cookie to the browser.
For backend systems, store secrets and refresh tokens in a protected environment such as a secret manager, encrypted database, or secured server-side configuration. Do not commit secrets to Git, Docker images, public build logs, or frontend environment files.
- Keep client secrets only on trusted servers.
- Do not place secrets in .env files that are bundled into frontend builds.
- Do not expose tokens in URLs, logs, analytics tools, or error reports.
- Use secure cookies for backend-managed browser sessions.
- Rotate and revoke refresh tokens when suspicious activity appears.
- Separate development, staging, and production OAuth clients.
Common Mistakes That Expose OAuth Secrets
A common mistake is assuming that minified JavaScript hides secrets. Minification makes code harder to read, but it does not provide real confidentiality. Anyone can inspect browser requests, app bundles, or source maps.
Another frequent issue is using one OAuth client for every platform. A web server app, SPA, Android app, iOS app, and desktop app often need different OAuth client registrations because they have different redirect URI rules and security properties.
| Mistake | Possible Result | Safer Alternative |
|---|---|---|
| Putting client_secret in JavaScript | Anyone can copy and reuse it | Use PKCE or move the exchange to a backend |
| Using the Implicit flow | Tokens may be exposed through browser redirects | Use Authorization Code flow with PKCE |
| Allowing wildcard redirect URIs | Codes or tokens may be sent to attacker-controlled pages | Register exact redirect URIs |
| Requesting too many scopes | A stolen token has more power than necessary | Use least-privilege scopes |
| Using embedded webviews for native login | User credentials and sessions may be exposed | Use the system browser or approved browser tabs |
When a Backend Is the Better Choice
PKCE protects public clients, but it does not make browser JavaScript a confidential environment. If the app handles sensitive account data, financial actions, private business records, admin controls, or high-value API access, a backend layer is usually safer.
With a backend, the browser never sees the OAuth client secret or long-lived refresh token. The server performs the token exchange and stores tokens in protected infrastructure. The browser receives only a session cookie configured with Secure, HttpOnly, and SameSite attributes.
In practice, this approach is often easier to audit because the most sensitive logic sits in one controlled environment. The trade-off is that you must secure sessions, prevent CSRF, monitor server logs, and protect your backend endpoints properly.
When to Get Professional Security Help
You should consider professional security help when OAuth protects money movement, health information, private customer data, admin dashboards, enterprise accounts, or regulated data. In those cases, a working login is not enough; the entire authorization design needs review.
Support from the identity provider is also useful when you are unsure which client type to choose, whether refresh tokens are allowed for public clients, or how redirect URI validation works for your platform. Provider-specific rules matter, and they can differ between Google, Microsoft, Auth0, Okta, GitHub, and other platforms.
At minimum, ask for a review of redirect handling, token storage, session cookies, CORS settings, scopes, refresh token behavior, logout behavior, and logging. These areas are where many real OAuth implementation mistakes appear first.
Conclusion
To implement OAuth 2.0 without exposing client secrets, treat browser, mobile, desktop, and extension apps as public clients. Use Authorization Code flow with PKCE instead of placing a permanent secret inside code that users can inspect.
For lower-risk public apps, PKCE, exact redirect URIs, state validation, limited scopes, short-lived tokens, and strong frontend security are essential. For sensitive systems, a backend-for-frontend or server-side token exchange is usually the safer architecture.
The best next step is to review your OAuth provider’s official documentation, confirm the correct client type, and test the complete authorization flow before launch. If the app handles sensitive data or payments, get a professional security review rather than relying only on a basic implementation checklist.
FAQ
1. Can I hide a client secret in frontend code?
No. Frontend code is delivered to the user’s device, which means it can be inspected, copied, modified, or reverse engineered. Even if the secret is minified, encoded, or placed in a build-time environment variable, it is still exposed once the app runs in the browser. A client secret only makes sense when it stays on a trusted backend server.
2. What should I use instead of a client secret in a SPA?
Use the Authorization Code flow with PKCE. PKCE allows a public client to prove that it initiated the authorization request without relying on a static secret. The app creates a temporary verifier, sends a derived challenge, and later uses the verifier during the token exchange. This is the modern approach for single-page applications that cannot protect secrets.
3. Is PKCE the same as a client secret?
No. PKCE is not a permanent secret and it does not make the app confidential. It is a temporary proof mechanism created for each authorization flow. A client secret is a long-lived credential that must remain private. PKCE helps protect against authorization code interception, while a client secret authenticates confidential clients that run on trusted servers.
4. Should mobile apps use OAuth client secrets?
Mobile apps should not depend on client secrets because app packages can be extracted and analyzed. A mobile app should normally use Authorization Code flow with PKCE and open the authorization request in the system browser or an approved browser tab. Embedded webviews should be avoided because they can weaken user trust and expose login credentials.
5. Is the Implicit flow still recommended?
For modern OAuth implementations, the Implicit flow is generally discouraged. It was created for older browser limitations, but it can expose tokens through redirects and browser history. Current best practice is to use Authorization Code flow with PKCE for browser-based public clients, assuming the authorization server supports it.
6. Can I store access tokens in localStorage?
You can, but it is usually not the safest option because JavaScript can read localStorage. If an attacker finds an XSS vulnerability, tokens stored there may be stolen. For browser apps, consider memory storage for short-lived tokens or a backend-for-frontend that keeps tokens server-side and uses secure, HttpOnly cookies for the browser session.
7. Do I still need the state parameter when using PKCE?
Yes. PKCE and state solve related but different problems. PKCE helps protect the authorization code exchange, while state helps link the authorization response to the request your app started. It also helps reduce the risk of cross-site request forgery and unexpected login responses. A strong implementation should use both.
8. What is the safest OAuth pattern for sensitive web apps?
For sensitive web apps, a backend-for-frontend or server-side web application is often safer than a pure SPA. The backend performs the token exchange, stores refresh tokens securely, and sends the browser a protected session cookie. This reduces the amount of sensitive OAuth material exposed to JavaScript and makes monitoring and auditing easier.
9. Should I request all OAuth scopes at once?
No. Request only the scopes needed for the current feature. Broad scopes increase risk because a stolen token can access more data or perform more actions. A better approach is least privilege: start with minimal access, then request additional scopes only when the user activates a feature that truly requires them.
10. Where should backend client secrets be stored?
Backend client secrets should be stored in protected server-side configuration, a secret manager, or another secured infrastructure system. They should not be committed to Git, exposed in frontend builds, printed in logs, copied into support tickets, or stored in shared documents. Production, staging, and development should use separate credentials whenever possible.
11. What redirect URI rules should I follow?
Register exact redirect URIs and avoid broad wildcards. The authorization server should only redirect users to trusted locations that belong to your application. Your app should also verify the response it receives. Loose redirect rules can allow attackers to capture authorization codes or confuse users into completing login flows for the wrong destination.
12. When should I contact the OAuth provider’s support?
Contact provider support when you are unsure about the correct client type, refresh token behavior, redirect URI rules, production verification, app consent screen requirements, or platform-specific restrictions. OAuth providers often have their own implementation details, and guessing can create security problems or cause the app to fail during review.
Editorial note: This article is for educational purposes and does not replace a professional security audit for applications that handle payments, private accounts, regulated data, or sensitive user information.
Official References
- IETF — RFC 9700 Best Current Practice for OAuth 2.0 Security
- IETF — RFC 7636 Proof Key for Code Exchange by OAuth Public Clients
- IETF — OAuth 2.0 for Browser-Based Applications
- RFC Editor — RFC 8252 OAuth 2.0 for Native Apps
- Google for Developers — Using OAuth 2.0 to Access Google APIs
