It seems like you're asking for feedback on this idea.
I apologize in advance for the length of this, I got started and then didn't know how to stop. If you'll bear with me....
As you know, the Apigee platform allows and encourages this. In fact the idea of an API Product is central to the Apigee system, and the API Product allows you to configure multiple distinct API proxies into it. Thinking of APIs as digital products that you share with developers outside the team that produces the APIs, is key to enabling digital integration, and digital innovation.
What is so special about the API Product mindset? The API Product is different than the API or the backing service; it is intended to be fit-for-purpose, suited for the experience the outside developer wants to build. Individual teams within a company ship individual APIs. Often they think in terms of
exposing what they have, whether "what they have" is a data source, a microservice, or some third party service. That exemplifies "inside-out thinking". People on the inside of an organization think "what do I have? I'll share it with outsiders."
Each API might be individually published. Maybe each API requires distinct credentials. Maybe each API has a distinct security model: one might require a simple API key, another uses an opaque OAuth token, another uses a token + HMAC, another uses a JWT... Each API is conceived in isolation.
In general, sharing is good, but sharing this way - "shipping the org
chart", aka Conway's Law, is non-optimal. In our opinion, it falls short of what organizations should do.
Apigeeks advocate "outside-in thinking", in which an API Product manager is charged with imagining what outside developers want, and then offering
that.
And this gets to the original question: Often what outside developers want or need is a set of multiple distinct APIs from multiple internal teams. So the API Product manager can assemble all of these APIs into a single API product, fit for the purpose that product manager is imagining.
Now we have an API product, and after the Product Manager publishes it to the developer portal, an outside developer can subscribe to that product, request authorization to use it. Upon approval (which may be automatic), the developer gets credentials that grant authorization to make requests to all of the APIs that are included in the product. This is the intent: one set of credentials that works on one PRODUCT, and there's no need for the outside developer to understand how that product is implemented, no need for that developer to have any insight into the individual APIs or backends that comprise that product.
- if key is compromised have to rotate keys again on all services
You've identified this as a drawback for the single-credential approach. I think you've got it backwards. This is an advantage. Rotating a single key is simple. On the other hand if the outside developer has to manage 3 or 4 different sets of credentials, and there's a security leak in which all of those credentials are potentially exposed (let's say the developer lost their laptop), then you need to rotate 3 or 4 different sets of credentials. With the API Product approach, there's just one credential to rotate.
- Security risk increases a bit when you have one set of credentials for multiple, unrelated services
I don't think of collecting multiple unrelated services together as a security risk, so much as, a cognitive burden on the consuming developer. If you issue a single credential for multiple unrelated services, that's not API Product thinking. That's... I don't know what that is. A bad idea? A way to confuse your developers?
The API Product mindset says, group RELATED services together, where the relation is "likely to be used by a single developer (or team) building a single user experience." Note: the relation is not "the team who built the service." That's inside-out perspective. Again, We advocate an outside-in perspective.
LinkedIn
Twitter
