How can I discourage sharing internal API keys within a company?Internal and external API architectureApplication internal APISharing authentication methods across API and web appREST API internal directory structure and RewriteEngineStrategy for keeping secret info such as API keys out of source control?Internal api development and committing procedureInternal API to public API - versioningWhy must API keys be kept private?

Rats biting off fuel line ( again and again and again )!

What exactly does "Disconnect from iPhone" do?

Authenticate users based on both user role, and requested operation

If a photon truly goes through both slits (at the same time), then why can't we detect it at both slits (at the same time)?

Would a warhorse allow its rider to approach a Dragon at all?

How can I find out where to buy uncommon (for the location) items while traveling?

Patent Agreement in Order to Graduate

How can a bigfoot hide from satellites?

I noticed an error in a graded exam during office hours. Should I give the student the lower grade?

Prevent function taking const std::string& from accepting 0

My PhD defense is next week and I am having negative thoughts about my work and knowledge. Any advice on how to tackle this?

Sent technical test that was impossible, other candidates completed it

Why is there potato in meatballs?

Get a character at a specified location

Is it possible to protect saved games on Nintendo Switch from being played by other users?

How can player characters, creatures and NPCs heal plants?

Is CCing the manager in first e-mail regarding urgent matter considered escalation?

Large products with glass doors

Last char on the line is being "left out" in many situations

Translate the French quote "Il n’y a pas d'amour, il n’y a que des preuves d’amour" to English?

Displaying vertex indices in Blender 2.8 using debug mode

What instructions should I give to an untrained passenger for Hand propping Cessna 172N as a pilot?

Triangular domino tiling of an almost regular hexagon

Novel about alien species made of gas rings?



How can I discourage sharing internal API keys within a company?


Internal and external API architectureApplication internal APISharing authentication methods across API and web appREST API internal directory structure and RewriteEngineStrategy for keeping secret info such as API keys out of source control?Internal api development and committing procedureInternal API to public API - versioningWhy must API keys be kept private?






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty
margin-bottom:0;









37


















We’re working on a new service – this service will potentially be called directly from applications on user devices. These applications will be developed and supported by multiple development teams from all over the organisation, all depending on the data we provide.



We’re keen to identify which applications are sending which requests, so that we can identify usage patterns and developers responsible. (For the avoidance of doubt, user authentication is handled separately.)



Our solution is to require API keys, one per application – then we have contact details for the development team.



We don’t want getting the API keys to be a source of friction, but we’re concerned that developers will share them to colleagues in other teams, meaning we can no longer identify traffic for just one application.



How can we incentivise developers not to share API keys internally?










share|improve this question






















  • 5





    How will these teams access the API? Via the internal network? Generally different teams are put in different subnetworks so you could enforce the use of a certain API key by network... Anyway the social solution is to tell them "it is important that you do not share this API key not for security but because we need the metrics of different users to improve it. If somebody asks you just tell them to ask us and we will gladly and efficiently provide an API key to them".

    – Giacomo Alzetta
    Sep 11 at 9:47






  • 3





    If you don't want people to share keys to colleagues, make it easy to include a configuration file that is ignored by the versioning system (so that the key is never commited) and also make it easy to create new keys. Nobody will bother sharing a secret key if another developer can easily create a new key by themselves. The problem with sharing personal keys is usually a problem caused by the fact that getting new keys takes time.

    – Sulthan
    Sep 11 at 17:52











  • Have you considered requiring registration when the application is first started? It could show a splash screen asking for the user's contact details (or whatever information it is that you need) and then issue the API key on the spot.

    – John Wu
    Sep 12 at 3:31












  • "How can we incentivise developers not to share API keys internally?" Simply stated, tie every key to the MAC address of the network card(s) in the computers that run them. Networking protocols prevents the same MAC addresses from being used in the same network, so that keeps people from using the same keys over and over again. I'd have made this into an answer, but I don't have the rep for it currently.

    – Blerg
    Sep 12 at 11:25











  • Curiously, I don't see the word "rotation" (as in key rotation -- credential expiration/rotation) anywhere on this page at the moment. Once someone obtains a key, does it have a finite lifetime after which it must be rotated out of use and replaced by a new one? If not, why not?

    – Michael - sqlbot
    Sep 12 at 12:36


















37


















We’re working on a new service – this service will potentially be called directly from applications on user devices. These applications will be developed and supported by multiple development teams from all over the organisation, all depending on the data we provide.



We’re keen to identify which applications are sending which requests, so that we can identify usage patterns and developers responsible. (For the avoidance of doubt, user authentication is handled separately.)



Our solution is to require API keys, one per application – then we have contact details for the development team.



We don’t want getting the API keys to be a source of friction, but we’re concerned that developers will share them to colleagues in other teams, meaning we can no longer identify traffic for just one application.



How can we incentivise developers not to share API keys internally?










share|improve this question






















  • 5





    How will these teams access the API? Via the internal network? Generally different teams are put in different subnetworks so you could enforce the use of a certain API key by network... Anyway the social solution is to tell them "it is important that you do not share this API key not for security but because we need the metrics of different users to improve it. If somebody asks you just tell them to ask us and we will gladly and efficiently provide an API key to them".

    – Giacomo Alzetta
    Sep 11 at 9:47






  • 3





    If you don't want people to share keys to colleagues, make it easy to include a configuration file that is ignored by the versioning system (so that the key is never commited) and also make it easy to create new keys. Nobody will bother sharing a secret key if another developer can easily create a new key by themselves. The problem with sharing personal keys is usually a problem caused by the fact that getting new keys takes time.

    – Sulthan
    Sep 11 at 17:52











  • Have you considered requiring registration when the application is first started? It could show a splash screen asking for the user's contact details (or whatever information it is that you need) and then issue the API key on the spot.

    – John Wu
    Sep 12 at 3:31












  • "How can we incentivise developers not to share API keys internally?" Simply stated, tie every key to the MAC address of the network card(s) in the computers that run them. Networking protocols prevents the same MAC addresses from being used in the same network, so that keeps people from using the same keys over and over again. I'd have made this into an answer, but I don't have the rep for it currently.

    – Blerg
    Sep 12 at 11:25











  • Curiously, I don't see the word "rotation" (as in key rotation -- credential expiration/rotation) anywhere on this page at the moment. Once someone obtains a key, does it have a finite lifetime after which it must be rotated out of use and replaced by a new one? If not, why not?

    – Michael - sqlbot
    Sep 12 at 12:36














37













37









37


5






We’re working on a new service – this service will potentially be called directly from applications on user devices. These applications will be developed and supported by multiple development teams from all over the organisation, all depending on the data we provide.



We’re keen to identify which applications are sending which requests, so that we can identify usage patterns and developers responsible. (For the avoidance of doubt, user authentication is handled separately.)



Our solution is to require API keys, one per application – then we have contact details for the development team.



We don’t want getting the API keys to be a source of friction, but we’re concerned that developers will share them to colleagues in other teams, meaning we can no longer identify traffic for just one application.



How can we incentivise developers not to share API keys internally?










share|improve this question
















We’re working on a new service – this service will potentially be called directly from applications on user devices. These applications will be developed and supported by multiple development teams from all over the organisation, all depending on the data we provide.



We’re keen to identify which applications are sending which requests, so that we can identify usage patterns and developers responsible. (For the avoidance of doubt, user authentication is handled separately.)



Our solution is to require API keys, one per application – then we have contact details for the development team.



We don’t want getting the API keys to be a source of friction, but we’re concerned that developers will share them to colleagues in other teams, meaning we can no longer identify traffic for just one application.



How can we incentivise developers not to share API keys internally?







api enterprise-development






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Sep 16 at 13:29









Community

1




1










asked Sep 11 at 7:05









OliOli

4792 silver badges3 bronze badges




4792 silver badges3 bronze badges










  • 5





    How will these teams access the API? Via the internal network? Generally different teams are put in different subnetworks so you could enforce the use of a certain API key by network... Anyway the social solution is to tell them "it is important that you do not share this API key not for security but because we need the metrics of different users to improve it. If somebody asks you just tell them to ask us and we will gladly and efficiently provide an API key to them".

    – Giacomo Alzetta
    Sep 11 at 9:47






  • 3





    If you don't want people to share keys to colleagues, make it easy to include a configuration file that is ignored by the versioning system (so that the key is never commited) and also make it easy to create new keys. Nobody will bother sharing a secret key if another developer can easily create a new key by themselves. The problem with sharing personal keys is usually a problem caused by the fact that getting new keys takes time.

    – Sulthan
    Sep 11 at 17:52











  • Have you considered requiring registration when the application is first started? It could show a splash screen asking for the user's contact details (or whatever information it is that you need) and then issue the API key on the spot.

    – John Wu
    Sep 12 at 3:31












  • "How can we incentivise developers not to share API keys internally?" Simply stated, tie every key to the MAC address of the network card(s) in the computers that run them. Networking protocols prevents the same MAC addresses from being used in the same network, so that keeps people from using the same keys over and over again. I'd have made this into an answer, but I don't have the rep for it currently.

    – Blerg
    Sep 12 at 11:25











  • Curiously, I don't see the word "rotation" (as in key rotation -- credential expiration/rotation) anywhere on this page at the moment. Once someone obtains a key, does it have a finite lifetime after which it must be rotated out of use and replaced by a new one? If not, why not?

    – Michael - sqlbot
    Sep 12 at 12:36













  • 5





    How will these teams access the API? Via the internal network? Generally different teams are put in different subnetworks so you could enforce the use of a certain API key by network... Anyway the social solution is to tell them "it is important that you do not share this API key not for security but because we need the metrics of different users to improve it. If somebody asks you just tell them to ask us and we will gladly and efficiently provide an API key to them".

    – Giacomo Alzetta
    Sep 11 at 9:47






  • 3





    If you don't want people to share keys to colleagues, make it easy to include a configuration file that is ignored by the versioning system (so that the key is never commited) and also make it easy to create new keys. Nobody will bother sharing a secret key if another developer can easily create a new key by themselves. The problem with sharing personal keys is usually a problem caused by the fact that getting new keys takes time.

    – Sulthan
    Sep 11 at 17:52











  • Have you considered requiring registration when the application is first started? It could show a splash screen asking for the user's contact details (or whatever information it is that you need) and then issue the API key on the spot.

    – John Wu
    Sep 12 at 3:31












  • "How can we incentivise developers not to share API keys internally?" Simply stated, tie every key to the MAC address of the network card(s) in the computers that run them. Networking protocols prevents the same MAC addresses from being used in the same network, so that keeps people from using the same keys over and over again. I'd have made this into an answer, but I don't have the rep for it currently.

    – Blerg
    Sep 12 at 11:25











  • Curiously, I don't see the word "rotation" (as in key rotation -- credential expiration/rotation) anywhere on this page at the moment. Once someone obtains a key, does it have a finite lifetime after which it must be rotated out of use and replaced by a new one? If not, why not?

    – Michael - sqlbot
    Sep 12 at 12:36








5




5





How will these teams access the API? Via the internal network? Generally different teams are put in different subnetworks so you could enforce the use of a certain API key by network... Anyway the social solution is to tell them "it is important that you do not share this API key not for security but because we need the metrics of different users to improve it. If somebody asks you just tell them to ask us and we will gladly and efficiently provide an API key to them".

– Giacomo Alzetta
Sep 11 at 9:47





How will these teams access the API? Via the internal network? Generally different teams are put in different subnetworks so you could enforce the use of a certain API key by network... Anyway the social solution is to tell them "it is important that you do not share this API key not for security but because we need the metrics of different users to improve it. If somebody asks you just tell them to ask us and we will gladly and efficiently provide an API key to them".

– Giacomo Alzetta
Sep 11 at 9:47




3




3





If you don't want people to share keys to colleagues, make it easy to include a configuration file that is ignored by the versioning system (so that the key is never commited) and also make it easy to create new keys. Nobody will bother sharing a secret key if another developer can easily create a new key by themselves. The problem with sharing personal keys is usually a problem caused by the fact that getting new keys takes time.

– Sulthan
Sep 11 at 17:52





If you don't want people to share keys to colleagues, make it easy to include a configuration file that is ignored by the versioning system (so that the key is never commited) and also make it easy to create new keys. Nobody will bother sharing a secret key if another developer can easily create a new key by themselves. The problem with sharing personal keys is usually a problem caused by the fact that getting new keys takes time.

– Sulthan
Sep 11 at 17:52













Have you considered requiring registration when the application is first started? It could show a splash screen asking for the user's contact details (or whatever information it is that you need) and then issue the API key on the spot.

– John Wu
Sep 12 at 3:31






Have you considered requiring registration when the application is first started? It could show a splash screen asking for the user's contact details (or whatever information it is that you need) and then issue the API key on the spot.

– John Wu
Sep 12 at 3:31














"How can we incentivise developers not to share API keys internally?" Simply stated, tie every key to the MAC address of the network card(s) in the computers that run them. Networking protocols prevents the same MAC addresses from being used in the same network, so that keeps people from using the same keys over and over again. I'd have made this into an answer, but I don't have the rep for it currently.

– Blerg
Sep 12 at 11:25





"How can we incentivise developers not to share API keys internally?" Simply stated, tie every key to the MAC address of the network card(s) in the computers that run them. Networking protocols prevents the same MAC addresses from being used in the same network, so that keeps people from using the same keys over and over again. I'd have made this into an answer, but I don't have the rep for it currently.

– Blerg
Sep 12 at 11:25













Curiously, I don't see the word "rotation" (as in key rotation -- credential expiration/rotation) anywhere on this page at the moment. Once someone obtains a key, does it have a finite lifetime after which it must be rotated out of use and replaced by a new one? If not, why not?

– Michael - sqlbot
Sep 12 at 12:36






Curiously, I don't see the word "rotation" (as in key rotation -- credential expiration/rotation) anywhere on this page at the moment. Once someone obtains a key, does it have a finite lifetime after which it must be rotated out of use and replaced by a new one? If not, why not?

– Michael - sqlbot
Sep 12 at 12:36











8 Answers
8






active

oldest

votes


















76



















In order to share those keys between teams, the teams need to talk to each other, agree to share, then share them. This takes time. So if a team can request API keys from you more quickly and more easily, there's no incentive to share.



And the easiest way for them to request those keys is for you to pre-empt them. Assuming you know all the other teams that will need API keys, create them and share them before making the service available to them.



There's one other incentive that you can offer: debugging support. Those teams will want your help when things don't quite work properly when they integrate their work with your service. Those API keys allow you to track their specific requests and thus to assist in debugging what's going wrong. So sell that as the reason for the keys, rather than "identify usage patterns and developers responsible", which sounds like you are spying on their activities.






share|improve this answer





















  • 2





    Re: sharing, in an ideal world you’re right - but you’re presupposing they have perfect information (though I can help by directing them to docs from the schema, root of the endpoint, and any errors) and cooperative management, and not the reality where all they may have is the endpoint and some code copied from another team which they were forwarded by a senior manager.

    – Oli
    Sep 11 at 7:27







  • 3





    Re: pre-empting, you’re absolutely right, we should aggressively create and send out keys to interested parties. What I didn’t mention is that some of these apps use a common framework/interface, and we could perhaps semi-automatically inject or enforce unique keys at that layer, but that doesn’t apply to all apps.

    – Oli
    Sep 11 at 7:29






  • 1





    @Ewan if you simply disable access to given key all the users will run to you - no need to chase them. And then you can give them unique keys :)

    – Alexei Levenkov
    Sep 11 at 20:58






  • 15





    Pre-empting should take this form: accessing the API without the key produces an error message with a link to the page where you apply for the key. Don't expect anyone to read documentation. Incentives don't work when no one knows about them.

    – candied_orange
    Sep 11 at 22:25







  • 1





    If error messages or debug logs were automatically emailed to an address linked to the key, anyone who wanted the data would have an incentive to use their own key - and anyone who's key was shared would have an incentive to track down the person who shared it and get them to stop.

    – Robin Bennett
    Sep 13 at 9:29


















20



















Good answers already, I just thought of a different approach which may or may not work for you.



Rather than issuing keys to be included you could require the header of requests to include the name of the front end application, to be created and formatted by the developer of the front end application, like web browsers do. That way front ends could still pretend to be a different application but there would be no benefit to doing that so that seems unlikely. Just let the front end identify itself and accept any non-empty string.






share|improve this answer


























  • That would make life somewhat harder if ownership of an application changed - for example, we could just update the API key details stored on our end, but if we accept free form text that requires the application to make a code change.

    – Oli
    Sep 11 at 9:32






  • 1





    @Oli If ownership of an application changed and the (new) developer would deem it appropriate to update the application's identity (which it truely has because someone else is maintaining it), what would be the problem? You could differentiate between pre ownership change and post ownership change, just regard them as two different applications. I would not expect any new owner to notice the name in the header anytime soon though.

    – Martin Maat
    Sep 11 at 9:48






  • 3





    This is what I do. have the client have a construction parameter which is the name of the app and/or use reflection to pull other stuff like the machine its running on, its version etc. The key thing is to enable you to report when people are NOT following your api policy

    – Ewan
    Sep 11 at 10:13






  • 1





    If the organization has a common approach to version control, e.g. everybody keeps their code on the org's GitHub server, have each app send an URL to it's repo and the commit hash from which it was built. The commit hash can be included in the code as part of the build process, so no need for developers to update anything. Having the repo URL lets you see who the owner is, and getting specific commits would let you notice behavior differences between versions.

    – Caleb
    Sep 11 at 12:36











  • @Caleb If things were centralized like that the OP would probably not have this problem. From what I understand the front end application developers are anonymous lot to the OP, with private ways of software development.

    – Martin Maat
    Sep 11 at 15:38


















16



















In short:



First: facilitation and benefits; If necessary: friction and police.



Some more words



Facilitation: First, make it easy for a team to get a new API key. For instance add a reminder in the corporate procedures for launching new projects, and offer an easy to use service to request a new keys, without asking for justification.



Benefits: Make the usage of an own API key be a benefit for the team or the product owner. For example, propose some feedback about app usage based on that key.



Friction: Depending on the key feature, you can create friction, for example if key is linked to somme app-defined domain (i.e. reusing keys would not necessarily give access to all desired services).



Policing: Finally, you may need to foresee some policing measures. For example, you may monitor usage of api functions by api key and after a given time to establish a baseline, inquiry about use of api parts which is not expected in view of the baseline. Or if this is not realistic, simply include in the corporate project-review checklists the verification that a valid key was used.



Remark: you may need to be very clear on your API key policy: Would a new major version require its own API key ? What with a fork, or if an app is split up ? what if another team is in charge, etc...






share|improve this answer



































    6



















    Generally the easiest way to get developers to "do the right thing", is to make it easy for them to do so.



    To that end I would suggest building a API key issuing web page/site.
    In its simplest form it could be just a login (ideally tied to your corporate AD/LDAP) and the page that just asks for the application name and issues the key.



    At the end of the day you can always revoke keys later, so all you really need the site to do is record who (username) requested the key and what (Application Name) they want to do with it - along with any info needed to revoke the key later.



    You could do something similar with a ticketing system, but at the end of the day it's very easy for me to copy and paste a key from one app to another, so it has to be really easy to request a new key, to avoid bad behavior.






    share|improve this answer

































      1



















      Be pro-active.



      Identify likely developers and GIVE them unique API keys in a secure channel, ahead of time. Provide an easy means of requesting new API keys. Provide an easy means of new people requesting new API keys. When new interns or hires join the team, give them a JIRA ticket or similar "Request an API key" with the steps in the description.



      Keep track of which API keys have been used, and which ones haven't. If Bob has submitted tickets in the project but hasn't been using his API keys, then he's probably borrowed someone else's.



      Have Management's Support. Don't be a Nosy Nancy going any making up rules that don't matter. Literally convince Management that it's important, and then they are the ones to convince the group that it's important. Don't work on convincing everyone.



      And the most annoying and tyranny-prone suggestion :
      Be aware of misuse, and crack down on the same day. Same hour is best. Don't say "Bad Naughty Developer" say "Here are the proper steps." If they do it repeatedly, disable the misused key. This hassles both the Sharer and the One Who Borrowed, and the sharer will say "No, do it properly" in the future. Avoid disabling keys that are in live projects.






      share|improve this answer

































        1




















        How can we incentivise developers not to share API keys internally?




        • Generate keys as a result of self-service application registration.


        • Require a point of contact before keys become active.

        • And ask them not to share. (Create a terms of service and/or tell them why it's better for them not to share.)

        You should also implement rate-limiting. This in itself could discourage sharing of keys. It protects your system to some extent against abusive applications. (And downright malicious ones.) And, it ensures you'll be somewhat informed prior to a massive increase in serviceable traffic. (Giving you time to add capacity, I hope!)



        And, with rate limiting, when an application does require a higher limit, it opens dialog with the POC registered for the key. You get an opportunity to ask if keys are being shared, explain why that's harmful and so forth, and you can offer additional keys when it's appropriate instead of the requested rate limit changes. Etc.






        share|improve this answer

































          0



















          One way to do things, especially if the teams use a shared build system (or at least a sufficiently common one) is to set up an internal server that creates and issues API keys (given a few basic bits of info about the product using it). Then use a script that grabs a new API key from the server for each build, or for each version update. Let devs run the script to get a different key for their local builds as well. (Where possible, automate this as part of the build so they don't even need to think about it.)



          This would let you tell whether it was something in production, QA, or dev, and at what version/build the problems started.






          share|improve this answer

































            0



















            The first and best thing you can do is to format the keys so that they include the application name in an easily readable form, and don't work if you change it.



            If it's obvious when teams are using the wrong key, then they'll endeavor not to.



            Then, periodically expire keys. You should do this anyway, and when a key is nearing expiration you can send a new one to the team that owns it. The team that uses a key will then be motivated to ensure that they are the team that owns it, so that they'll get the new one when it expires.






            share|improve this answer





















            • 1





              in practice though expiring keys may be too much of a hurdle for the adopting application - i can see managers saying "fuggetaboutit" as it's just going to be trouble later.

              – davidbak
              Sep 12 at 23:38











            protected by gnat Sep 12 at 8:03



            Thank you for your interest in this question.
            Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



            Would you like to answer one of these unanswered questions instead?














            8 Answers
            8






            active

            oldest

            votes








            8 Answers
            8






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            76



















            In order to share those keys between teams, the teams need to talk to each other, agree to share, then share them. This takes time. So if a team can request API keys from you more quickly and more easily, there's no incentive to share.



            And the easiest way for them to request those keys is for you to pre-empt them. Assuming you know all the other teams that will need API keys, create them and share them before making the service available to them.



            There's one other incentive that you can offer: debugging support. Those teams will want your help when things don't quite work properly when they integrate their work with your service. Those API keys allow you to track their specific requests and thus to assist in debugging what's going wrong. So sell that as the reason for the keys, rather than "identify usage patterns and developers responsible", which sounds like you are spying on their activities.






            share|improve this answer





















            • 2





              Re: sharing, in an ideal world you’re right - but you’re presupposing they have perfect information (though I can help by directing them to docs from the schema, root of the endpoint, and any errors) and cooperative management, and not the reality where all they may have is the endpoint and some code copied from another team which they were forwarded by a senior manager.

              – Oli
              Sep 11 at 7:27







            • 3





              Re: pre-empting, you’re absolutely right, we should aggressively create and send out keys to interested parties. What I didn’t mention is that some of these apps use a common framework/interface, and we could perhaps semi-automatically inject or enforce unique keys at that layer, but that doesn’t apply to all apps.

              – Oli
              Sep 11 at 7:29






            • 1





              @Ewan if you simply disable access to given key all the users will run to you - no need to chase them. And then you can give them unique keys :)

              – Alexei Levenkov
              Sep 11 at 20:58






            • 15





              Pre-empting should take this form: accessing the API without the key produces an error message with a link to the page where you apply for the key. Don't expect anyone to read documentation. Incentives don't work when no one knows about them.

              – candied_orange
              Sep 11 at 22:25







            • 1





              If error messages or debug logs were automatically emailed to an address linked to the key, anyone who wanted the data would have an incentive to use their own key - and anyone who's key was shared would have an incentive to track down the person who shared it and get them to stop.

              – Robin Bennett
              Sep 13 at 9:29















            76



















            In order to share those keys between teams, the teams need to talk to each other, agree to share, then share them. This takes time. So if a team can request API keys from you more quickly and more easily, there's no incentive to share.



            And the easiest way for them to request those keys is for you to pre-empt them. Assuming you know all the other teams that will need API keys, create them and share them before making the service available to them.



            There's one other incentive that you can offer: debugging support. Those teams will want your help when things don't quite work properly when they integrate their work with your service. Those API keys allow you to track their specific requests and thus to assist in debugging what's going wrong. So sell that as the reason for the keys, rather than "identify usage patterns and developers responsible", which sounds like you are spying on their activities.






            share|improve this answer





















            • 2





              Re: sharing, in an ideal world you’re right - but you’re presupposing they have perfect information (though I can help by directing them to docs from the schema, root of the endpoint, and any errors) and cooperative management, and not the reality where all they may have is the endpoint and some code copied from another team which they were forwarded by a senior manager.

              – Oli
              Sep 11 at 7:27







            • 3





              Re: pre-empting, you’re absolutely right, we should aggressively create and send out keys to interested parties. What I didn’t mention is that some of these apps use a common framework/interface, and we could perhaps semi-automatically inject or enforce unique keys at that layer, but that doesn’t apply to all apps.

              – Oli
              Sep 11 at 7:29






            • 1





              @Ewan if you simply disable access to given key all the users will run to you - no need to chase them. And then you can give them unique keys :)

              – Alexei Levenkov
              Sep 11 at 20:58






            • 15





              Pre-empting should take this form: accessing the API without the key produces an error message with a link to the page where you apply for the key. Don't expect anyone to read documentation. Incentives don't work when no one knows about them.

              – candied_orange
              Sep 11 at 22:25







            • 1





              If error messages or debug logs were automatically emailed to an address linked to the key, anyone who wanted the data would have an incentive to use their own key - and anyone who's key was shared would have an incentive to track down the person who shared it and get them to stop.

              – Robin Bennett
              Sep 13 at 9:29













            76















            76











            76









            In order to share those keys between teams, the teams need to talk to each other, agree to share, then share them. This takes time. So if a team can request API keys from you more quickly and more easily, there's no incentive to share.



            And the easiest way for them to request those keys is for you to pre-empt them. Assuming you know all the other teams that will need API keys, create them and share them before making the service available to them.



            There's one other incentive that you can offer: debugging support. Those teams will want your help when things don't quite work properly when they integrate their work with your service. Those API keys allow you to track their specific requests and thus to assist in debugging what's going wrong. So sell that as the reason for the keys, rather than "identify usage patterns and developers responsible", which sounds like you are spying on their activities.






            share|improve this answer














            In order to share those keys between teams, the teams need to talk to each other, agree to share, then share them. This takes time. So if a team can request API keys from you more quickly and more easily, there's no incentive to share.



            And the easiest way for them to request those keys is for you to pre-empt them. Assuming you know all the other teams that will need API keys, create them and share them before making the service available to them.



            There's one other incentive that you can offer: debugging support. Those teams will want your help when things don't quite work properly when they integrate their work with your service. Those API keys allow you to track their specific requests and thus to assist in debugging what's going wrong. So sell that as the reason for the keys, rather than "identify usage patterns and developers responsible", which sounds like you are spying on their activities.







            share|improve this answer













            share|improve this answer




            share|improve this answer










            answered Sep 11 at 7:20









            David ArnoDavid Arno

            33.3k8 gold badges69 silver badges105 bronze badges




            33.3k8 gold badges69 silver badges105 bronze badges










            • 2





              Re: sharing, in an ideal world you’re right - but you’re presupposing they have perfect information (though I can help by directing them to docs from the schema, root of the endpoint, and any errors) and cooperative management, and not the reality where all they may have is the endpoint and some code copied from another team which they were forwarded by a senior manager.

              – Oli
              Sep 11 at 7:27







            • 3





              Re: pre-empting, you’re absolutely right, we should aggressively create and send out keys to interested parties. What I didn’t mention is that some of these apps use a common framework/interface, and we could perhaps semi-automatically inject or enforce unique keys at that layer, but that doesn’t apply to all apps.

              – Oli
              Sep 11 at 7:29






            • 1





              @Ewan if you simply disable access to given key all the users will run to you - no need to chase them. And then you can give them unique keys :)

              – Alexei Levenkov
              Sep 11 at 20:58






            • 15





              Pre-empting should take this form: accessing the API without the key produces an error message with a link to the page where you apply for the key. Don't expect anyone to read documentation. Incentives don't work when no one knows about them.

              – candied_orange
              Sep 11 at 22:25







            • 1





              If error messages or debug logs were automatically emailed to an address linked to the key, anyone who wanted the data would have an incentive to use their own key - and anyone who's key was shared would have an incentive to track down the person who shared it and get them to stop.

              – Robin Bennett
              Sep 13 at 9:29












            • 2





              Re: sharing, in an ideal world you’re right - but you’re presupposing they have perfect information (though I can help by directing them to docs from the schema, root of the endpoint, and any errors) and cooperative management, and not the reality where all they may have is the endpoint and some code copied from another team which they were forwarded by a senior manager.

              – Oli
              Sep 11 at 7:27







            • 3





              Re: pre-empting, you’re absolutely right, we should aggressively create and send out keys to interested parties. What I didn’t mention is that some of these apps use a common framework/interface, and we could perhaps semi-automatically inject or enforce unique keys at that layer, but that doesn’t apply to all apps.

              – Oli
              Sep 11 at 7:29






            • 1





              @Ewan if you simply disable access to given key all the users will run to you - no need to chase them. And then you can give them unique keys :)

              – Alexei Levenkov
              Sep 11 at 20:58






            • 15





              Pre-empting should take this form: accessing the API without the key produces an error message with a link to the page where you apply for the key. Don't expect anyone to read documentation. Incentives don't work when no one knows about them.

              – candied_orange
              Sep 11 at 22:25







            • 1





              If error messages or debug logs were automatically emailed to an address linked to the key, anyone who wanted the data would have an incentive to use their own key - and anyone who's key was shared would have an incentive to track down the person who shared it and get them to stop.

              – Robin Bennett
              Sep 13 at 9:29







            2




            2





            Re: sharing, in an ideal world you’re right - but you’re presupposing they have perfect information (though I can help by directing them to docs from the schema, root of the endpoint, and any errors) and cooperative management, and not the reality where all they may have is the endpoint and some code copied from another team which they were forwarded by a senior manager.

            – Oli
            Sep 11 at 7:27






            Re: sharing, in an ideal world you’re right - but you’re presupposing they have perfect information (though I can help by directing them to docs from the schema, root of the endpoint, and any errors) and cooperative management, and not the reality where all they may have is the endpoint and some code copied from another team which they were forwarded by a senior manager.

            – Oli
            Sep 11 at 7:27





            3




            3





            Re: pre-empting, you’re absolutely right, we should aggressively create and send out keys to interested parties. What I didn’t mention is that some of these apps use a common framework/interface, and we could perhaps semi-automatically inject or enforce unique keys at that layer, but that doesn’t apply to all apps.

            – Oli
            Sep 11 at 7:29





            Re: pre-empting, you’re absolutely right, we should aggressively create and send out keys to interested parties. What I didn’t mention is that some of these apps use a common framework/interface, and we could perhaps semi-automatically inject or enforce unique keys at that layer, but that doesn’t apply to all apps.

            – Oli
            Sep 11 at 7:29




            1




            1





            @Ewan if you simply disable access to given key all the users will run to you - no need to chase them. And then you can give them unique keys :)

            – Alexei Levenkov
            Sep 11 at 20:58





            @Ewan if you simply disable access to given key all the users will run to you - no need to chase them. And then you can give them unique keys :)

            – Alexei Levenkov
            Sep 11 at 20:58




            15




            15





            Pre-empting should take this form: accessing the API without the key produces an error message with a link to the page where you apply for the key. Don't expect anyone to read documentation. Incentives don't work when no one knows about them.

            – candied_orange
            Sep 11 at 22:25






            Pre-empting should take this form: accessing the API without the key produces an error message with a link to the page where you apply for the key. Don't expect anyone to read documentation. Incentives don't work when no one knows about them.

            – candied_orange
            Sep 11 at 22:25





            1




            1





            If error messages or debug logs were automatically emailed to an address linked to the key, anyone who wanted the data would have an incentive to use their own key - and anyone who's key was shared would have an incentive to track down the person who shared it and get them to stop.

            – Robin Bennett
            Sep 13 at 9:29





            If error messages or debug logs were automatically emailed to an address linked to the key, anyone who wanted the data would have an incentive to use their own key - and anyone who's key was shared would have an incentive to track down the person who shared it and get them to stop.

            – Robin Bennett
            Sep 13 at 9:29













            20



















            Good answers already, I just thought of a different approach which may or may not work for you.



            Rather than issuing keys to be included you could require the header of requests to include the name of the front end application, to be created and formatted by the developer of the front end application, like web browsers do. That way front ends could still pretend to be a different application but there would be no benefit to doing that so that seems unlikely. Just let the front end identify itself and accept any non-empty string.






            share|improve this answer


























            • That would make life somewhat harder if ownership of an application changed - for example, we could just update the API key details stored on our end, but if we accept free form text that requires the application to make a code change.

              – Oli
              Sep 11 at 9:32






            • 1





              @Oli If ownership of an application changed and the (new) developer would deem it appropriate to update the application's identity (which it truely has because someone else is maintaining it), what would be the problem? You could differentiate between pre ownership change and post ownership change, just regard them as two different applications. I would not expect any new owner to notice the name in the header anytime soon though.

              – Martin Maat
              Sep 11 at 9:48






            • 3





              This is what I do. have the client have a construction parameter which is the name of the app and/or use reflection to pull other stuff like the machine its running on, its version etc. The key thing is to enable you to report when people are NOT following your api policy

              – Ewan
              Sep 11 at 10:13






            • 1





              If the organization has a common approach to version control, e.g. everybody keeps their code on the org's GitHub server, have each app send an URL to it's repo and the commit hash from which it was built. The commit hash can be included in the code as part of the build process, so no need for developers to update anything. Having the repo URL lets you see who the owner is, and getting specific commits would let you notice behavior differences between versions.

              – Caleb
              Sep 11 at 12:36











            • @Caleb If things were centralized like that the OP would probably not have this problem. From what I understand the front end application developers are anonymous lot to the OP, with private ways of software development.

              – Martin Maat
              Sep 11 at 15:38















            20



















            Good answers already, I just thought of a different approach which may or may not work for you.



            Rather than issuing keys to be included you could require the header of requests to include the name of the front end application, to be created and formatted by the developer of the front end application, like web browsers do. That way front ends could still pretend to be a different application but there would be no benefit to doing that so that seems unlikely. Just let the front end identify itself and accept any non-empty string.






            share|improve this answer


























            • That would make life somewhat harder if ownership of an application changed - for example, we could just update the API key details stored on our end, but if we accept free form text that requires the application to make a code change.

              – Oli
              Sep 11 at 9:32






            • 1





              @Oli If ownership of an application changed and the (new) developer would deem it appropriate to update the application's identity (which it truely has because someone else is maintaining it), what would be the problem? You could differentiate between pre ownership change and post ownership change, just regard them as two different applications. I would not expect any new owner to notice the name in the header anytime soon though.

              – Martin Maat
              Sep 11 at 9:48






            • 3





              This is what I do. have the client have a construction parameter which is the name of the app and/or use reflection to pull other stuff like the machine its running on, its version etc. The key thing is to enable you to report when people are NOT following your api policy

              – Ewan
              Sep 11 at 10:13






            • 1





              If the organization has a common approach to version control, e.g. everybody keeps their code on the org's GitHub server, have each app send an URL to it's repo and the commit hash from which it was built. The commit hash can be included in the code as part of the build process, so no need for developers to update anything. Having the repo URL lets you see who the owner is, and getting specific commits would let you notice behavior differences between versions.

              – Caleb
              Sep 11 at 12:36











            • @Caleb If things were centralized like that the OP would probably not have this problem. From what I understand the front end application developers are anonymous lot to the OP, with private ways of software development.

              – Martin Maat
              Sep 11 at 15:38













            20















            20











            20









            Good answers already, I just thought of a different approach which may or may not work for you.



            Rather than issuing keys to be included you could require the header of requests to include the name of the front end application, to be created and formatted by the developer of the front end application, like web browsers do. That way front ends could still pretend to be a different application but there would be no benefit to doing that so that seems unlikely. Just let the front end identify itself and accept any non-empty string.






            share|improve this answer














            Good answers already, I just thought of a different approach which may or may not work for you.



            Rather than issuing keys to be included you could require the header of requests to include the name of the front end application, to be created and formatted by the developer of the front end application, like web browsers do. That way front ends could still pretend to be a different application but there would be no benefit to doing that so that seems unlikely. Just let the front end identify itself and accept any non-empty string.







            share|improve this answer













            share|improve this answer




            share|improve this answer










            answered Sep 11 at 9:28









            Martin MaatMartin Maat

            10.5k3 gold badges14 silver badges40 bronze badges




            10.5k3 gold badges14 silver badges40 bronze badges















            • That would make life somewhat harder if ownership of an application changed - for example, we could just update the API key details stored on our end, but if we accept free form text that requires the application to make a code change.

              – Oli
              Sep 11 at 9:32






            • 1





              @Oli If ownership of an application changed and the (new) developer would deem it appropriate to update the application's identity (which it truely has because someone else is maintaining it), what would be the problem? You could differentiate between pre ownership change and post ownership change, just regard them as two different applications. I would not expect any new owner to notice the name in the header anytime soon though.

              – Martin Maat
              Sep 11 at 9:48






            • 3





              This is what I do. have the client have a construction parameter which is the name of the app and/or use reflection to pull other stuff like the machine its running on, its version etc. The key thing is to enable you to report when people are NOT following your api policy

              – Ewan
              Sep 11 at 10:13






            • 1





              If the organization has a common approach to version control, e.g. everybody keeps their code on the org's GitHub server, have each app send an URL to it's repo and the commit hash from which it was built. The commit hash can be included in the code as part of the build process, so no need for developers to update anything. Having the repo URL lets you see who the owner is, and getting specific commits would let you notice behavior differences between versions.

              – Caleb
              Sep 11 at 12:36











            • @Caleb If things were centralized like that the OP would probably not have this problem. From what I understand the front end application developers are anonymous lot to the OP, with private ways of software development.

              – Martin Maat
              Sep 11 at 15:38

















            • That would make life somewhat harder if ownership of an application changed - for example, we could just update the API key details stored on our end, but if we accept free form text that requires the application to make a code change.

              – Oli
              Sep 11 at 9:32






            • 1





              @Oli If ownership of an application changed and the (new) developer would deem it appropriate to update the application's identity (which it truely has because someone else is maintaining it), what would be the problem? You could differentiate between pre ownership change and post ownership change, just regard them as two different applications. I would not expect any new owner to notice the name in the header anytime soon though.

              – Martin Maat
              Sep 11 at 9:48






            • 3





              This is what I do. have the client have a construction parameter which is the name of the app and/or use reflection to pull other stuff like the machine its running on, its version etc. The key thing is to enable you to report when people are NOT following your api policy

              – Ewan
              Sep 11 at 10:13






            • 1





              If the organization has a common approach to version control, e.g. everybody keeps their code on the org's GitHub server, have each app send an URL to it's repo and the commit hash from which it was built. The commit hash can be included in the code as part of the build process, so no need for developers to update anything. Having the repo URL lets you see who the owner is, and getting specific commits would let you notice behavior differences between versions.

              – Caleb
              Sep 11 at 12:36











            • @Caleb If things were centralized like that the OP would probably not have this problem. From what I understand the front end application developers are anonymous lot to the OP, with private ways of software development.

              – Martin Maat
              Sep 11 at 15:38
















            That would make life somewhat harder if ownership of an application changed - for example, we could just update the API key details stored on our end, but if we accept free form text that requires the application to make a code change.

            – Oli
            Sep 11 at 9:32





            That would make life somewhat harder if ownership of an application changed - for example, we could just update the API key details stored on our end, but if we accept free form text that requires the application to make a code change.

            – Oli
            Sep 11 at 9:32




            1




            1





            @Oli If ownership of an application changed and the (new) developer would deem it appropriate to update the application's identity (which it truely has because someone else is maintaining it), what would be the problem? You could differentiate between pre ownership change and post ownership change, just regard them as two different applications. I would not expect any new owner to notice the name in the header anytime soon though.

            – Martin Maat
            Sep 11 at 9:48





            @Oli If ownership of an application changed and the (new) developer would deem it appropriate to update the application's identity (which it truely has because someone else is maintaining it), what would be the problem? You could differentiate between pre ownership change and post ownership change, just regard them as two different applications. I would not expect any new owner to notice the name in the header anytime soon though.

            – Martin Maat
            Sep 11 at 9:48




            3




            3





            This is what I do. have the client have a construction parameter which is the name of the app and/or use reflection to pull other stuff like the machine its running on, its version etc. The key thing is to enable you to report when people are NOT following your api policy

            – Ewan
            Sep 11 at 10:13





            This is what I do. have the client have a construction parameter which is the name of the app and/or use reflection to pull other stuff like the machine its running on, its version etc. The key thing is to enable you to report when people are NOT following your api policy

            – Ewan
            Sep 11 at 10:13




            1




            1





            If the organization has a common approach to version control, e.g. everybody keeps their code on the org's GitHub server, have each app send an URL to it's repo and the commit hash from which it was built. The commit hash can be included in the code as part of the build process, so no need for developers to update anything. Having the repo URL lets you see who the owner is, and getting specific commits would let you notice behavior differences between versions.

            – Caleb
            Sep 11 at 12:36





            If the organization has a common approach to version control, e.g. everybody keeps their code on the org's GitHub server, have each app send an URL to it's repo and the commit hash from which it was built. The commit hash can be included in the code as part of the build process, so no need for developers to update anything. Having the repo URL lets you see who the owner is, and getting specific commits would let you notice behavior differences between versions.

            – Caleb
            Sep 11 at 12:36













            @Caleb If things were centralized like that the OP would probably not have this problem. From what I understand the front end application developers are anonymous lot to the OP, with private ways of software development.

            – Martin Maat
            Sep 11 at 15:38





            @Caleb If things were centralized like that the OP would probably not have this problem. From what I understand the front end application developers are anonymous lot to the OP, with private ways of software development.

            – Martin Maat
            Sep 11 at 15:38











            16



















            In short:



            First: facilitation and benefits; If necessary: friction and police.



            Some more words



            Facilitation: First, make it easy for a team to get a new API key. For instance add a reminder in the corporate procedures for launching new projects, and offer an easy to use service to request a new keys, without asking for justification.



            Benefits: Make the usage of an own API key be a benefit for the team or the product owner. For example, propose some feedback about app usage based on that key.



            Friction: Depending on the key feature, you can create friction, for example if key is linked to somme app-defined domain (i.e. reusing keys would not necessarily give access to all desired services).



            Policing: Finally, you may need to foresee some policing measures. For example, you may monitor usage of api functions by api key and after a given time to establish a baseline, inquiry about use of api parts which is not expected in view of the baseline. Or if this is not realistic, simply include in the corporate project-review checklists the verification that a valid key was used.



            Remark: you may need to be very clear on your API key policy: Would a new major version require its own API key ? What with a fork, or if an app is split up ? what if another team is in charge, etc...






            share|improve this answer
































              16



















              In short:



              First: facilitation and benefits; If necessary: friction and police.



              Some more words



              Facilitation: First, make it easy for a team to get a new API key. For instance add a reminder in the corporate procedures for launching new projects, and offer an easy to use service to request a new keys, without asking for justification.



              Benefits: Make the usage of an own API key be a benefit for the team or the product owner. For example, propose some feedback about app usage based on that key.



              Friction: Depending on the key feature, you can create friction, for example if key is linked to somme app-defined domain (i.e. reusing keys would not necessarily give access to all desired services).



              Policing: Finally, you may need to foresee some policing measures. For example, you may monitor usage of api functions by api key and after a given time to establish a baseline, inquiry about use of api parts which is not expected in view of the baseline. Or if this is not realistic, simply include in the corporate project-review checklists the verification that a valid key was used.



              Remark: you may need to be very clear on your API key policy: Would a new major version require its own API key ? What with a fork, or if an app is split up ? what if another team is in charge, etc...






              share|improve this answer






























                16















                16











                16









                In short:



                First: facilitation and benefits; If necessary: friction and police.



                Some more words



                Facilitation: First, make it easy for a team to get a new API key. For instance add a reminder in the corporate procedures for launching new projects, and offer an easy to use service to request a new keys, without asking for justification.



                Benefits: Make the usage of an own API key be a benefit for the team or the product owner. For example, propose some feedback about app usage based on that key.



                Friction: Depending on the key feature, you can create friction, for example if key is linked to somme app-defined domain (i.e. reusing keys would not necessarily give access to all desired services).



                Policing: Finally, you may need to foresee some policing measures. For example, you may monitor usage of api functions by api key and after a given time to establish a baseline, inquiry about use of api parts which is not expected in view of the baseline. Or if this is not realistic, simply include in the corporate project-review checklists the verification that a valid key was used.



                Remark: you may need to be very clear on your API key policy: Would a new major version require its own API key ? What with a fork, or if an app is split up ? what if another team is in charge, etc...






                share|improve this answer
















                In short:



                First: facilitation and benefits; If necessary: friction and police.



                Some more words



                Facilitation: First, make it easy for a team to get a new API key. For instance add a reminder in the corporate procedures for launching new projects, and offer an easy to use service to request a new keys, without asking for justification.



                Benefits: Make the usage of an own API key be a benefit for the team or the product owner. For example, propose some feedback about app usage based on that key.



                Friction: Depending on the key feature, you can create friction, for example if key is linked to somme app-defined domain (i.e. reusing keys would not necessarily give access to all desired services).



                Policing: Finally, you may need to foresee some policing measures. For example, you may monitor usage of api functions by api key and after a given time to establish a baseline, inquiry about use of api parts which is not expected in view of the baseline. Or if this is not realistic, simply include in the corporate project-review checklists the verification that a valid key was used.



                Remark: you may need to be very clear on your API key policy: Would a new major version require its own API key ? What with a fork, or if an app is split up ? what if another team is in charge, etc...







                share|improve this answer















                share|improve this answer




                share|improve this answer








                edited Sep 13 at 22:05

























                answered Sep 11 at 7:54









                ChristopheChristophe

                32.7k5 gold badges47 silver badges87 bronze badges




                32.7k5 gold badges47 silver badges87 bronze badges
























                    6



















                    Generally the easiest way to get developers to "do the right thing", is to make it easy for them to do so.



                    To that end I would suggest building a API key issuing web page/site.
                    In its simplest form it could be just a login (ideally tied to your corporate AD/LDAP) and the page that just asks for the application name and issues the key.



                    At the end of the day you can always revoke keys later, so all you really need the site to do is record who (username) requested the key and what (Application Name) they want to do with it - along with any info needed to revoke the key later.



                    You could do something similar with a ticketing system, but at the end of the day it's very easy for me to copy and paste a key from one app to another, so it has to be really easy to request a new key, to avoid bad behavior.






                    share|improve this answer






























                      6



















                      Generally the easiest way to get developers to "do the right thing", is to make it easy for them to do so.



                      To that end I would suggest building a API key issuing web page/site.
                      In its simplest form it could be just a login (ideally tied to your corporate AD/LDAP) and the page that just asks for the application name and issues the key.



                      At the end of the day you can always revoke keys later, so all you really need the site to do is record who (username) requested the key and what (Application Name) they want to do with it - along with any info needed to revoke the key later.



                      You could do something similar with a ticketing system, but at the end of the day it's very easy for me to copy and paste a key from one app to another, so it has to be really easy to request a new key, to avoid bad behavior.






                      share|improve this answer




























                        6















                        6











                        6









                        Generally the easiest way to get developers to "do the right thing", is to make it easy for them to do so.



                        To that end I would suggest building a API key issuing web page/site.
                        In its simplest form it could be just a login (ideally tied to your corporate AD/LDAP) and the page that just asks for the application name and issues the key.



                        At the end of the day you can always revoke keys later, so all you really need the site to do is record who (username) requested the key and what (Application Name) they want to do with it - along with any info needed to revoke the key later.



                        You could do something similar with a ticketing system, but at the end of the day it's very easy for me to copy and paste a key from one app to another, so it has to be really easy to request a new key, to avoid bad behavior.






                        share|improve this answer














                        Generally the easiest way to get developers to "do the right thing", is to make it easy for them to do so.



                        To that end I would suggest building a API key issuing web page/site.
                        In its simplest form it could be just a login (ideally tied to your corporate AD/LDAP) and the page that just asks for the application name and issues the key.



                        At the end of the day you can always revoke keys later, so all you really need the site to do is record who (username) requested the key and what (Application Name) they want to do with it - along with any info needed to revoke the key later.



                        You could do something similar with a ticketing system, but at the end of the day it's very easy for me to copy and paste a key from one app to another, so it has to be really easy to request a new key, to avoid bad behavior.







                        share|improve this answer













                        share|improve this answer




                        share|improve this answer










                        answered Sep 12 at 0:57









                        DavidTDavidT

                        691 bronze badge




                        691 bronze badge
























                            1



















                            Be pro-active.



                            Identify likely developers and GIVE them unique API keys in a secure channel, ahead of time. Provide an easy means of requesting new API keys. Provide an easy means of new people requesting new API keys. When new interns or hires join the team, give them a JIRA ticket or similar "Request an API key" with the steps in the description.



                            Keep track of which API keys have been used, and which ones haven't. If Bob has submitted tickets in the project but hasn't been using his API keys, then he's probably borrowed someone else's.



                            Have Management's Support. Don't be a Nosy Nancy going any making up rules that don't matter. Literally convince Management that it's important, and then they are the ones to convince the group that it's important. Don't work on convincing everyone.



                            And the most annoying and tyranny-prone suggestion :
                            Be aware of misuse, and crack down on the same day. Same hour is best. Don't say "Bad Naughty Developer" say "Here are the proper steps." If they do it repeatedly, disable the misused key. This hassles both the Sharer and the One Who Borrowed, and the sharer will say "No, do it properly" in the future. Avoid disabling keys that are in live projects.






                            share|improve this answer






























                              1



















                              Be pro-active.



                              Identify likely developers and GIVE them unique API keys in a secure channel, ahead of time. Provide an easy means of requesting new API keys. Provide an easy means of new people requesting new API keys. When new interns or hires join the team, give them a JIRA ticket or similar "Request an API key" with the steps in the description.



                              Keep track of which API keys have been used, and which ones haven't. If Bob has submitted tickets in the project but hasn't been using his API keys, then he's probably borrowed someone else's.



                              Have Management's Support. Don't be a Nosy Nancy going any making up rules that don't matter. Literally convince Management that it's important, and then they are the ones to convince the group that it's important. Don't work on convincing everyone.



                              And the most annoying and tyranny-prone suggestion :
                              Be aware of misuse, and crack down on the same day. Same hour is best. Don't say "Bad Naughty Developer" say "Here are the proper steps." If they do it repeatedly, disable the misused key. This hassles both the Sharer and the One Who Borrowed, and the sharer will say "No, do it properly" in the future. Avoid disabling keys that are in live projects.






                              share|improve this answer




























                                1















                                1











                                1









                                Be pro-active.



                                Identify likely developers and GIVE them unique API keys in a secure channel, ahead of time. Provide an easy means of requesting new API keys. Provide an easy means of new people requesting new API keys. When new interns or hires join the team, give them a JIRA ticket or similar "Request an API key" with the steps in the description.



                                Keep track of which API keys have been used, and which ones haven't. If Bob has submitted tickets in the project but hasn't been using his API keys, then he's probably borrowed someone else's.



                                Have Management's Support. Don't be a Nosy Nancy going any making up rules that don't matter. Literally convince Management that it's important, and then they are the ones to convince the group that it's important. Don't work on convincing everyone.



                                And the most annoying and tyranny-prone suggestion :
                                Be aware of misuse, and crack down on the same day. Same hour is best. Don't say "Bad Naughty Developer" say "Here are the proper steps." If they do it repeatedly, disable the misused key. This hassles both the Sharer and the One Who Borrowed, and the sharer will say "No, do it properly" in the future. Avoid disabling keys that are in live projects.






                                share|improve this answer














                                Be pro-active.



                                Identify likely developers and GIVE them unique API keys in a secure channel, ahead of time. Provide an easy means of requesting new API keys. Provide an easy means of new people requesting new API keys. When new interns or hires join the team, give them a JIRA ticket or similar "Request an API key" with the steps in the description.



                                Keep track of which API keys have been used, and which ones haven't. If Bob has submitted tickets in the project but hasn't been using his API keys, then he's probably borrowed someone else's.



                                Have Management's Support. Don't be a Nosy Nancy going any making up rules that don't matter. Literally convince Management that it's important, and then they are the ones to convince the group that it's important. Don't work on convincing everyone.



                                And the most annoying and tyranny-prone suggestion :
                                Be aware of misuse, and crack down on the same day. Same hour is best. Don't say "Bad Naughty Developer" say "Here are the proper steps." If they do it repeatedly, disable the misused key. This hassles both the Sharer and the One Who Borrowed, and the sharer will say "No, do it properly" in the future. Avoid disabling keys that are in live projects.







                                share|improve this answer













                                share|improve this answer




                                share|improve this answer










                                answered Sep 11 at 20:52









                                Christopher HostageChristopher Hostage

                                1192 bronze badges




                                1192 bronze badges
























                                    1




















                                    How can we incentivise developers not to share API keys internally?




                                    • Generate keys as a result of self-service application registration.


                                    • Require a point of contact before keys become active.

                                    • And ask them not to share. (Create a terms of service and/or tell them why it's better for them not to share.)

                                    You should also implement rate-limiting. This in itself could discourage sharing of keys. It protects your system to some extent against abusive applications. (And downright malicious ones.) And, it ensures you'll be somewhat informed prior to a massive increase in serviceable traffic. (Giving you time to add capacity, I hope!)



                                    And, with rate limiting, when an application does require a higher limit, it opens dialog with the POC registered for the key. You get an opportunity to ask if keys are being shared, explain why that's harmful and so forth, and you can offer additional keys when it's appropriate instead of the requested rate limit changes. Etc.






                                    share|improve this answer






























                                      1




















                                      How can we incentivise developers not to share API keys internally?




                                      • Generate keys as a result of self-service application registration.


                                      • Require a point of contact before keys become active.

                                      • And ask them not to share. (Create a terms of service and/or tell them why it's better for them not to share.)

                                      You should also implement rate-limiting. This in itself could discourage sharing of keys. It protects your system to some extent against abusive applications. (And downright malicious ones.) And, it ensures you'll be somewhat informed prior to a massive increase in serviceable traffic. (Giving you time to add capacity, I hope!)



                                      And, with rate limiting, when an application does require a higher limit, it opens dialog with the POC registered for the key. You get an opportunity to ask if keys are being shared, explain why that's harmful and so forth, and you can offer additional keys when it's appropriate instead of the requested rate limit changes. Etc.






                                      share|improve this answer




























                                        1















                                        1











                                        1










                                        How can we incentivise developers not to share API keys internally?




                                        • Generate keys as a result of self-service application registration.


                                        • Require a point of contact before keys become active.

                                        • And ask them not to share. (Create a terms of service and/or tell them why it's better for them not to share.)

                                        You should also implement rate-limiting. This in itself could discourage sharing of keys. It protects your system to some extent against abusive applications. (And downright malicious ones.) And, it ensures you'll be somewhat informed prior to a massive increase in serviceable traffic. (Giving you time to add capacity, I hope!)



                                        And, with rate limiting, when an application does require a higher limit, it opens dialog with the POC registered for the key. You get an opportunity to ask if keys are being shared, explain why that's harmful and so forth, and you can offer additional keys when it's appropriate instead of the requested rate limit changes. Etc.






                                        share|improve this answer















                                        How can we incentivise developers not to share API keys internally?




                                        • Generate keys as a result of self-service application registration.


                                        • Require a point of contact before keys become active.

                                        • And ask them not to share. (Create a terms of service and/or tell them why it's better for them not to share.)

                                        You should also implement rate-limiting. This in itself could discourage sharing of keys. It protects your system to some extent against abusive applications. (And downright malicious ones.) And, it ensures you'll be somewhat informed prior to a massive increase in serviceable traffic. (Giving you time to add capacity, I hope!)



                                        And, with rate limiting, when an application does require a higher limit, it opens dialog with the POC registered for the key. You get an opportunity to ask if keys are being shared, explain why that's harmful and so forth, and you can offer additional keys when it's appropriate instead of the requested rate limit changes. Etc.







                                        share|improve this answer













                                        share|improve this answer




                                        share|improve this answer










                                        answered Sep 14 at 3:03









                                        svidgensvidgen

                                        12.3k2 gold badges30 silver badges55 bronze badges




                                        12.3k2 gold badges30 silver badges55 bronze badges
























                                            0



















                                            One way to do things, especially if the teams use a shared build system (or at least a sufficiently common one) is to set up an internal server that creates and issues API keys (given a few basic bits of info about the product using it). Then use a script that grabs a new API key from the server for each build, or for each version update. Let devs run the script to get a different key for their local builds as well. (Where possible, automate this as part of the build so they don't even need to think about it.)



                                            This would let you tell whether it was something in production, QA, or dev, and at what version/build the problems started.






                                            share|improve this answer






























                                              0



















                                              One way to do things, especially if the teams use a shared build system (or at least a sufficiently common one) is to set up an internal server that creates and issues API keys (given a few basic bits of info about the product using it). Then use a script that grabs a new API key from the server for each build, or for each version update. Let devs run the script to get a different key for their local builds as well. (Where possible, automate this as part of the build so they don't even need to think about it.)



                                              This would let you tell whether it was something in production, QA, or dev, and at what version/build the problems started.






                                              share|improve this answer




























                                                0















                                                0











                                                0









                                                One way to do things, especially if the teams use a shared build system (or at least a sufficiently common one) is to set up an internal server that creates and issues API keys (given a few basic bits of info about the product using it). Then use a script that grabs a new API key from the server for each build, or for each version update. Let devs run the script to get a different key for their local builds as well. (Where possible, automate this as part of the build so they don't even need to think about it.)



                                                This would let you tell whether it was something in production, QA, or dev, and at what version/build the problems started.






                                                share|improve this answer














                                                One way to do things, especially if the teams use a shared build system (or at least a sufficiently common one) is to set up an internal server that creates and issues API keys (given a few basic bits of info about the product using it). Then use a script that grabs a new API key from the server for each build, or for each version update. Let devs run the script to get a different key for their local builds as well. (Where possible, automate this as part of the build so they don't even need to think about it.)



                                                This would let you tell whether it was something in production, QA, or dev, and at what version/build the problems started.







                                                share|improve this answer













                                                share|improve this answer




                                                share|improve this answer










                                                answered Sep 12 at 2:06









                                                MiralMiral

                                                1011 bronze badge




                                                1011 bronze badge
























                                                    0



















                                                    The first and best thing you can do is to format the keys so that they include the application name in an easily readable form, and don't work if you change it.



                                                    If it's obvious when teams are using the wrong key, then they'll endeavor not to.



                                                    Then, periodically expire keys. You should do this anyway, and when a key is nearing expiration you can send a new one to the team that owns it. The team that uses a key will then be motivated to ensure that they are the team that owns it, so that they'll get the new one when it expires.






                                                    share|improve this answer





















                                                    • 1





                                                      in practice though expiring keys may be too much of a hurdle for the adopting application - i can see managers saying "fuggetaboutit" as it's just going to be trouble later.

                                                      – davidbak
                                                      Sep 12 at 23:38
















                                                    0



















                                                    The first and best thing you can do is to format the keys so that they include the application name in an easily readable form, and don't work if you change it.



                                                    If it's obvious when teams are using the wrong key, then they'll endeavor not to.



                                                    Then, periodically expire keys. You should do this anyway, and when a key is nearing expiration you can send a new one to the team that owns it. The team that uses a key will then be motivated to ensure that they are the team that owns it, so that they'll get the new one when it expires.






                                                    share|improve this answer





















                                                    • 1





                                                      in practice though expiring keys may be too much of a hurdle for the adopting application - i can see managers saying "fuggetaboutit" as it's just going to be trouble later.

                                                      – davidbak
                                                      Sep 12 at 23:38














                                                    0















                                                    0











                                                    0









                                                    The first and best thing you can do is to format the keys so that they include the application name in an easily readable form, and don't work if you change it.



                                                    If it's obvious when teams are using the wrong key, then they'll endeavor not to.



                                                    Then, periodically expire keys. You should do this anyway, and when a key is nearing expiration you can send a new one to the team that owns it. The team that uses a key will then be motivated to ensure that they are the team that owns it, so that they'll get the new one when it expires.






                                                    share|improve this answer














                                                    The first and best thing you can do is to format the keys so that they include the application name in an easily readable form, and don't work if you change it.



                                                    If it's obvious when teams are using the wrong key, then they'll endeavor not to.



                                                    Then, periodically expire keys. You should do this anyway, and when a key is nearing expiration you can send a new one to the team that owns it. The team that uses a key will then be motivated to ensure that they are the team that owns it, so that they'll get the new one when it expires.







                                                    share|improve this answer













                                                    share|improve this answer




                                                    share|improve this answer










                                                    answered Sep 12 at 3:40









                                                    Matt TimmermansMatt Timmermans

                                                    3811 silver badge3 bronze badges




                                                    3811 silver badge3 bronze badges










                                                    • 1





                                                      in practice though expiring keys may be too much of a hurdle for the adopting application - i can see managers saying "fuggetaboutit" as it's just going to be trouble later.

                                                      – davidbak
                                                      Sep 12 at 23:38













                                                    • 1





                                                      in practice though expiring keys may be too much of a hurdle for the adopting application - i can see managers saying "fuggetaboutit" as it's just going to be trouble later.

                                                      – davidbak
                                                      Sep 12 at 23:38








                                                    1




                                                    1





                                                    in practice though expiring keys may be too much of a hurdle for the adopting application - i can see managers saying "fuggetaboutit" as it's just going to be trouble later.

                                                    – davidbak
                                                    Sep 12 at 23:38






                                                    in practice though expiring keys may be too much of a hurdle for the adopting application - i can see managers saying "fuggetaboutit" as it's just going to be trouble later.

                                                    – davidbak
                                                    Sep 12 at 23:38






                                                    protected by gnat Sep 12 at 8:03



                                                    Thank you for your interest in this question.
                                                    Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



                                                    Would you like to answer one of these unanswered questions instead?



                                                    Popular posts from this blog

                                                    Tamil (spriik) Luke uk diar | Nawigatjuun

                                                    Align equal signs while including text over equalitiesAMS align: left aligned text/math plus multicolumn alignmentMultiple alignmentsAligning equations in multiple placesNumbering and aligning an equation with multiple columnsHow to align one equation with another multline equationUsing \ in environments inside the begintabularxNumber equations and preserving alignment of equal signsHow can I align equations to the left and to the right?Double equation alignment problem within align enviromentAligned within align: Why are they right-aligned?

                                                    Training a classifier when some of the features are unknownWhy does Gradient Boosting regression predict negative values when there are no negative y-values in my training set?How to improve an existing (trained) classifier?What is effect when I set up some self defined predisctor variables?Why Matlab neural network classification returns decimal values on prediction dataset?Fitting and transforming text data in training, testing, and validation setsHow to quantify the performance of the classifier (multi-class SVM) using the test data?How do I control for some patients providing multiple samples in my training data?Training and Test setTraining a convolutional neural network for image denoising in MatlabShouldn't an autoencoder with #(neurons in hidden layer) = #(neurons in input layer) be “perfect”?