Best Practices for Consumer/API key provisioning and management

[#1]

We're having some spirited debate on best way to manage API keys for our vendors. Some promote a per-vendor key, others per-developer key. Additionally, some want a key-per-environment, so we can authorize a key against our API product per environment (you can hit production once you've seen you can properly hit test). For this, we're thinking of creating different API products for each environment, which seems like a hacky workaround.

Finally, it appears that the same API key is generated for each developer app- not each product that developer. I can see both sides of that argument.

What (best) practices are recommended by Apigee and/or the community for these areas?

Thanks...

[willwitman]

Hi Daniel,

What's the difference between a vendor and a developer in your model? Is what you're calling a vendor an external client developer? While what you call a developer is someone internal who's actually building/testing your APIs? Or are you referring to an external vendor who has multiple developers?

I'm not sure about the idea of authorizing keys per environment, but might not understand your use case. If a key is valid, it will be valid whether the API is deployed in test or prod.

Also, I don't follow your second question "it appears that the same API key is generated for each developer app- not each product that developer" -- seems like something's missing in this sentence.

If you don't mind elaborating a bit more, this seems like a good discussion to have in the community! It's possible we can do a better job of explaining the relationships between products, developer apps, developers, environments, etc.

[#3]

For us, we are providing APIs for other companies to incorporate into their products - so ACME, Inc. employees a developer, Johnny A. Pee-eye. ACME is the vendor, Johnny is one of their developers. If the API key is associated with Johnny - what if he leaves ACME? A level of organization of API developers, collecting them into organizations, would help us (and I expect others) a LOT. We're planning on adding a custom attribute for our own usage for now, but that seems like a bandaid.

Most of our APIs are non-idempotent and fairly critical - verifying behavior in a testing environment prior to being granted production access is, in our case, very important. If we can only authorize a key across _all_ environments, that's a bit problematic.

For the second question - create two products, then grant access to a developer app - it's a little weird that the product list (in the Developer Apps > {app name} menu) list each app with the same Consumer Key and Secret repeated. If the Key is at the App level (which makes sense) - then have it at the app level - showing it per Product is counter-intuitive... Hope that clears it up a little.

[jonesfloyd]

In order to really lock products down, an API proxy needs to be added to them. Just specifying resource patterns does not cause them to restrict access. Since API proxies have unique Host addresses, you'd need proxies for different environments anyway (assuming the hosts are different between environments). So you'd have "test" APIs / Products and "prod" APIs / products.

Regarding keys, yes, they're generated for developer apps, which are associated with an email address. But that's really just a formality. You could create an app with a global email like all@acme.com, and any Acme developer or app that makes an API call uses the same key. If a developer joins or leaves Acme, no biggie. You can also periodically update keys as well. For analytics, which is where keys uniquely identify the traffic coming through, the email identifies the company in reports.

Maybe consider creating one test app per comany and one prod app per company, and allow product access accordingly.

Does that make sense or am I just confusing the matter?

[DChiesa]

@Daniel Greene

Products can be restricted to a particular environment. Eg, test, or prod.

See the screenshot below.

If you'd like to grant developers access to a particular environment, the product is a good way to do it. Not a hacky approach at app. This is one of the intended uses of the API Product entity.

Also, it's true that an API key is generated for each developer app, and there is, by default, not a unique API key for different API proxies. Having multiple independent keys for different API proxies, all to be managed by a single app -- well that seems like a headache I wouldn't want to give to my developers.