Apigee can broker user-to-service connections, or service-to-service connections.
In the case of user-to-service connections, typically you want to authenticate the user, as well as the app. There are OAuthV2 grant types defined in the IETF RFC 6749 for this purpose: authorization_code and password. Part of what you are doing, it sounds like, is an extension of the idea of a password grant; you are using the Firebase ID token as the proof of authentication of the user. And then you would need to accomplish the authentication of the client app (client ID, API key, or client credentials, etc) in the normal way.
In the case of service-to-service connections, the server (or proxy) authenticates only the calling service, or client, or app. Sometimes it's not quite authentication; it's identification. In the case of using an API key to identify a client, that API key is often not a secret, because it's embedded in a web app or similar. So we can call that "light authentication" or really just identification. Often clients will use a client_credentials grant to authenticate, and that helps a little bit but again, not for web apps.
RFC 7523 suggests an alternative way to authenticate client apps, and that is with a self-signed JWT. This is a nifty bump in the security of client authentication. I just published a sample that shows how to do this in Apigee X. (screencast to come) Basically the client exchanges a self-signed JWT for an Apigee-generated access token, and then can use the latter in requests for service. The authorization is checked by Apigee based on the API Product configuration for the registered app.
I don't understand the intersection, in your case, between the user-authenticated flows (using Firebase ID token to obtain an access token) and the service-to-service flows (which should use client credentials, or jwt-bearer to get an access token). I'm not sure how that works.
@sk123 wrote:
Is there a best practice around creating these types of admin apps that aren't necessarily associated with a developer?
There is always a developer. Apps don't write themselves! (Unless you are using an advanced version of Gemini AI. But then I guess Gemini would be the developer, eh?) The credentials for admin apps or service-to-service apps, are "owned" by the person who develops the apps. I think maybe you are imagining that apps that act as headless systems (service to service), have no developer. That doesn't make sense to me. There is a developer. Someone needs to build the app. In headless apps, there is no USER. But that is a different thing.
There are three populations of people in the API world
- API Publishers. People who build and publish APIs, make them available for consumption via an API catalog.
- API Developers. Aka consumer developers. These people peruse the API catalog, request credentials, build apps that i nvoke the APIs.
- App Users. These are end-users who may interact with the API-powered Apps.
The final group is not always required, as in the case of automated or headless (aka no UI) systems.
There is actually ANOTHER group of "principals" involved in the ecosystem. And that is apps, or clients. Apps also have identity; in the Apigee world, that's the client id + secret, usually.
Each different group of principals is authenticated differently.
- API publishers need to authenticate to the Google cloud console. Sometimes there is an automated CI/CD process that assists here.
- App Developers get authenticated to the developer portal.
- App Users can be authenticated by some external IdP, which is app- or platform- specific. Maybe firebase, maybe Okta, etc.
- Apps themselves authenticate via client credentials.
LinkedIn
Twitter
