Off-band API key management challenge

[sgoto]

Hey all,

   Apologies for the spam, but wanted to kick off a few things I had in mind in preparation to meeting you all in person next week :)

   Has anyone looked at exposing publicly facing APIs that DO NOT require any API KEY management (e.g. quota management, pricing, etc)?

   Context: as a consumer of a large number of APIs, I cannot afford to "sign-up to each and every person's API keys". I need a machine-automatable mechanism to start using APIs without ever having to go through a human-readable documentation, specifically signing up to API KEYs.

  I call this the API management challenge (which happens even at RMM L3): if your API is behind an API KEY user-readable flow, it is not discoverable.

  We found a few mechanisms that I think generally works, but it takes a little bit of, lets call, an "open mind" :) Before I get into proposals, just wondering:

  Has anyone looked into making their APIs behave more like web pages (as far as API management goes)? That is, NOT require AT ALL an API KEY sign up, and solve things at run-time (note that API KEYS are VERY different than user auth)?

  Has anyone looked into reverting the sign-up game and requiring all clients to identify themselves WHILE making the requests (as opposed as a pre-setup  process)? Sort of like saying "hey, i'm domain x.com, please allow my request to pass through? xthxbye"

  For example, if a CLIENT of your API sent you idTokens, wouldn't that be sufficient for your SERVER to perform all that it needs to perform (e.g. quota management, DDOS protections, etc)? If not, what else goes into your API KEYs management that requires you to use them?

  Sam

--

f u cn rd ths u cn b a gd prgmr !

[mca]

so, one way to look at this is "how can we make API access onboarding fully automated?" or "how can we do realtime API key management?"

would love to see what you are thinking here and maybe discuss it at API Craft next week.

mca

+1.859.757.1449
skype:mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[Jack Repenning]

On Jul 21, 2015, at 11:32 PM, sgoto <samue...@gmail.com> wrote:

  Has anyone looked into making their APIs behave more like web pages (as far as API management goes)? That is, NOT require AT ALL an API KEY sign up, and solve things at run-time (note that API KEYS are VERY different than user auth)?

Many web pages require some sort of sign-up, these days often including a confirmation loop via email. Indeed, the confirmation loop is generally perceived as having the primary purpose of *excluding* automated, untouched-by-human-hands access (what you want).

API Keys are "different from user auth" in that their main-line use flow is simpler, but this handy short-cut is, IME, always grounded in an established user login session based on an established user identity confirmed by one of those pesky register-and-confirm human-mediated workflows.

Even APIs whose main purpose is purely public tend, these days, to require an API key (hence developer-user, hence identity, hence confirmation), for monitoring (who's using our API?), value-demonstration (see, boss? this API stuff makes us money!), and control (e.g., DOS blocking). Google famously learned that, a few years ago, causing them to add keys to even their most basic APIs. Key management ensures that such reporting and control covers the expected user, not some spoofing DOSer.

So, yeah: someone has investigated this, and learned that it's dangerous, and now it's a recognized Best Practice to do what's causing you grief. I'm sympathetic to your problem of "thousands of APIs," but I 'm not optimistic you'll be able to convince "thousands of API providers" to lower the draw bridge and let  you in, unless you can find some other way to keep Melvin Malice out. Having negotiated security protocols, a bit, I'm even more doubtful that this convincing will somehow be easier or quicker than just slogging through the thousands of registration and key-allocation procedures.

-- 
Jack Repenning
Repenni...@gmail.com

[Venkatachalapathi G]

Bit different opinion in a question format.  

Wouldn't API key is proxy for live human and runs on top of users context ... ? 

Rgds/Venkat

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

«.¸¸.·´¨`»Venkat«´¨`·.¸¸.»

[Jack Repenning]

On Jul 22, 2015, at 4:10 PM, Venkatachalapathi G <gvp...@gmail.com> wrote:

Wouldn't API key is proxy for live human and runs on top of users context ... ? 

Not necessarily.

* Some API Key systems allow a key to do only some limited subset of what the user can do (e.g., read-only).

* Some "user context" isn't appropriate for an API (e.g., "last message viewed").

-- 
Jack Repenning
Repenni...@gmail.com

[sgoto]

On Wed, Jul 22, 2015 at 11:02 AM, mca <m...@amundsen.com> wrote:

so, one way to look at this is "how can we make API access onboarding fully automated?" or "how can we do realtime API key management?"

Right, that's a really good way to look at this problem.

[sgoto]

On Wed, Jul 22, 2015 at 12:20 PM, Jack Repenning <repenni...@gmail.com> wrote:

On Jul 21, 2015, at 11:32 PM, sgoto <samue...@gmail.com> wrote:

  Has anyone looked into making their APIs behave more like web pages (as far as API management goes)? That is, NOT require AT ALL an API KEY sign up, and solve things at run-time (note that API KEYS are VERY different than user auth)?

Many web pages require some sort of sign-up, these days often including a confirmation loop via email. Indeed, the confirmation loop is generally perceived as having the primary purpose of *excluding* automated, untouched-by-human-hands access (what you want).

API Keys are "different from user auth" in that their main-line use flow is simpler, but this handy short-cut is, IME, always grounded in an established user login session based on an established user identity confirmed by one of those pesky register-and-confirm human-mediated workflows.

I think that's fair, but it is orthogonal to what I'm debating: applying user-specific "quota" is totally fine.

For example, if you look at the opentable page for booking appointments with restaurants:

http://opentable.com/cascal

You can get pretty far in this flow (e.g. you can check what time is available given your specific search criteria) BEFORE it requires the user to sign-in.

Why does an API need to constrain that very first call (finding what's available given your specific search criteria) BEHIND an API KEY?

 

Even APIs whose main purpose is purely public tend, these days, to require an API key (hence developer-user, hence identity, hence confirmation), for monitoring (who's using our API?), value-demonstration (see, boss? this API stuff makes us money!), and control (e.g., DOS blocking). Google famously learned that, a few years ago, causing them to add keys to even their most basic APIs. Key management ensures that such reporting and control covers the expected user, not some spoofing DOSer.

So, yeah: someone has investigated this, and learned that it's dangerous, and now it's a recognized Best Practice to do what's causing you grief. I'm sympathetic to your problem of "thousands of APIs," but I 'm not optimistic you'll be able to convince "thousands of API providers" to lower the draw bridge and let  you in, unless you can find some other way to keep Melvin Malice out. Having negotiated security protocols, a bit, I'm even more doubtful that this convincing will somehow be easier or quicker than just slogging through the thousands of registration and key-allocation procedures.

-- 
Jack Repenning
Repenni...@gmail.com

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

[sgoto]

On Wed, Jul 22, 2015 at 12:20 PM, Jack Repenning <repenni...@gmail.com> wrote:

On Jul 21, 2015, at 11:32 PM, sgoto <samue...@gmail.com> wrote:

  Has anyone looked into making their APIs behave more like web pages (as far as API management goes)? That is, NOT require AT ALL an API KEY sign up, and solve things at run-time (note that API KEYS are VERY different than user auth)?

Many web pages require some sort of sign-up, these days often including a confirmation loop via email. Indeed, the confirmation loop is generally perceived as having the primary purpose of *excluding* automated, untouched-by-human-hands access (what you want).

API Keys are "different from user auth" in that their main-line use flow is simpler, but this handy short-cut is, IME, always grounded in an established user login session based on an established user identity confirmed by one of those pesky register-and-confirm human-mediated workflows.

Even APIs whose main purpose is purely public tend, these days, to require an API key (hence developer-user, hence identity, hence confirmation), for monitoring (who's using our API?), value-demonstration (see, boss? this API stuff makes us money!), and control (e.g., DOS blocking). Google famously learned that, a few years ago, causing them to add keys to even their most basic APIs. Key management ensures that such reporting and control covers the expected user, not some spoofing DOSer.

So, yeah: someone has investigated this, and learned that it's dangerous, and now it's a recognized Best Practice to do what's causing you grief. I'm sympathetic to your problem of "thousands of APIs," but I 'm not optimistic you'll be able to convince "thousands of API providers" to lower the draw bridge and let  you in, unless you can find some other way to keep Melvin Malice out.

 This is what I'm exploring: revert the API management flow. "identify thyself" as opposed to "register".

 A CLIENT of your API sends you idTokens (to identify itself - at the domain level, not at the user level) to allow your server to perform to provide CLIENT-specific protections (e.g. quota management, DDOS protections, etc).

 Sort of like running "sudo" on the linux terminal: if the OS thinks the specific user has the right to run that call, let them.

 

Having negotiated security protocols, a bit, I'm even more doubtful that this convincing will somehow be easier or quicker than just slogging through the thousands of registration and key-allocation procedures.

-- 
Jack Repenning
Repenni...@gmail.com

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.