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
LinkedIn
Twitter
