Sharing Graph API secret key in open source projects RRS feed

  • Question

  • Hi,

    I'm developing a very simple open source application that reads/writes user information from the Graph API. I am following AuthV2 user authentication methods.

    Since this is an open source project, the client ID and secret key would be exposed in the code. Would this be okay as long as the API calls are within the rate limits? I am not using any paid API services.

    I am aware the right answer to this is to not share the secret key. But I would really like to avoid having all users signing up for a Graph API key (which has quite a lot of steps) just to use this simple application.

    Tuesday, November 12, 2019 9:47 AM

All replies

  • It would be fine saving the client id and secret key in the code as long as you are not publishing it for production use.    The user's of your application will not be signing up for any Graph API key, it is your application which is going to store the Client Id/Client Secret either in your application configuration (web.config) file or in Azure Key Vault. Ideally, you should be storing the client Id/ client secret in a Azure Key Vault for any application you have deployed in production on Azure.
    Tuesday, November 12, 2019 5:46 PM
  • Thanks for the response.

    I have several follow-up questions.

    Since this is an open source project, I think it would fall under "publishing it for production use". Would you agree?

    I understand that the client id/secret could be stored somewhere safe in web services. But what if the application is a standalone program that is run locally and directly interacts with the Graph API without a custom server in between?

    To be more specific, my project is intended to be downloaded and run directly on the user's machine, so the API key/secret has to be available somewhere in the source code or package for the user to use it. If the API key/secret is not packaged in the (open source) software, then the only way the user can use the program is to register another API key/secret to use the program, which I would like to avoid if possible.

    Hope that made sense. Thanks.

    Wednesday, November 13, 2019 7:26 AM