Get hands-on experience with 20+ free Google Cloud products and $300 in free credit for new customers.

How to authenticate a client app (JavaScript based complete frontend application)

Is there any way to authenticate a client app(JavaScript based complete frontend application) only & without user authentication(since it can be used by any user) which consumes a Apigee API proxy?

Is there any solution exits other than Authorization Code Flow with Proof Key for Code Exchange (PKCE), where user authorization(user consent) is involved.

The goal is to authenticate a client app only in Apigee which is consuming an Apigee API proxy & not its user's(who is using it) 

Looking forward for any answers, suggestions. Thank you.

Regards,
Meenakshi Sundar.

  

Solved Solved
0 4 448
1 ACCEPTED SOLUTION

Hi @meenakshisundar 

I think I see where you're coming from - you want to authenticate a JavaScript-based frontend app itself, without involving the end user. Essentially, a system-to-system style interaction, but originating from a browser, not a backend.

The core issue here is that frontend apps can't be truly authenticated. Authentication implies the ability to prove identity using something secret - a client_secret, private key, or signed assertion. But browser-based apps can't securely store any of that. Whatever you embed in the code can be extracted and reused by anyone.

At best, you can identify the app using something like a client_id, but you can't trust it in the same way you'd trust a backend system. In Apigee, the VerifyAPIKey policy is often used for this purpose: it lets you associate an API key with a known app and check that key on incoming requests. But this is just identification - it doesn't establish trust or grant access to sensitive resources.

In most production-grade Apigee setups, frontend apps access protected APIs on behalf of a user. The user logs in, gets an access token, and the token is used to authorise API calls. That's where the actual permission logic happens - based on user's token scopes and claims, not the app.

That said, if your API truly doesn't require user context - for example, it just returns a list of publicly available products - then using VerifyAPIKey is a valid and common approach.

So in summary: yes, you can identify a frontend app in Apigee using an API key, but not authenticate it in the strong sense. And for anything beyond public or anonymous access, the right way is still to rely on user authentication and access tokens.

Hope that helps

Best regards,
Nikita

View solution in original post

4 REPLIES 4

@meenakshisundar - can you expand on "& not its user's(who is using it)" pls as its not very clear? Did you mean its used or not used by users?

Hi @ssvaidyanathan,

I means (as @nmarkevich mentioned in this comment), I want to authenticate a JavaScript-based frontend app itself, without involving the end user. Essentially, a system-to-system style interaction, but originating from a browser, not a backend.

Hi @meenakshisundar 

I think I see where you're coming from - you want to authenticate a JavaScript-based frontend app itself, without involving the end user. Essentially, a system-to-system style interaction, but originating from a browser, not a backend.

The core issue here is that frontend apps can't be truly authenticated. Authentication implies the ability to prove identity using something secret - a client_secret, private key, or signed assertion. But browser-based apps can't securely store any of that. Whatever you embed in the code can be extracted and reused by anyone.

At best, you can identify the app using something like a client_id, but you can't trust it in the same way you'd trust a backend system. In Apigee, the VerifyAPIKey policy is often used for this purpose: it lets you associate an API key with a known app and check that key on incoming requests. But this is just identification - it doesn't establish trust or grant access to sensitive resources.

In most production-grade Apigee setups, frontend apps access protected APIs on behalf of a user. The user logs in, gets an access token, and the token is used to authorise API calls. That's where the actual permission logic happens - based on user's token scopes and claims, not the app.

That said, if your API truly doesn't require user context - for example, it just returns a list of publicly available products - then using VerifyAPIKey is a valid and common approach.

So in summary: yes, you can identify a frontend app in Apigee using an API key, but not authenticate it in the strong sense. And for anything beyond public or anonymous access, the right way is still to rely on user authentication and access tokens.

Hope that helps

Best regards,
Nikita

Hi @meenakshisundar ,

Yes — if you want to authenticate only the client app (not the user), you can use client credentials flow (client ID + client secret) or API key-based authentication.

Options in Apigee:
– Use an API key: the frontend app includes the key in the request; Apigee checks it with an API Key Verification policy.
– Use a client credentials token: the app (ideally from a backend, not directly in frontend JS) gets an access token from Apigee by sending its client ID + secret, then uses that token to call the proxy.

Important caution:
For frontend-only apps, exposing client secrets or API keys directly in JavaScript is risky because users can view the code. To secure the setup:
– Prefer a lightweight backend or API gateway to hold secrets and handle token exchange.
– If you must go frontend-only, use public API keys with strict quotas and referrer/IP restrictions.

Top Solution Authors