Providing Subscription keys - my account or a shared account?

Our University is working with a third party developer who requires the subscription keys for the Payments API. I assume I should provide these under a shared / organisational account, rather than my own account, because if I leave and my account is disabled, then the key will stop working? Or does it not work like this? Thanks!

Comments

  • Ben Wong
    Ben Wong Blackbaud Employee
    Tenth Anniversary Kudos 3 Name Dropper Participant

    @John Bird, that's a great question. Since the introduction of multi-factor authentication (MFA) we generally advise against shared accounts. If the 3rd party developer is working on a temporary basis, when at some point the app will be transferred, then it's best to have a developer at the University own the Payments API subscription. That will save you from having to switch the API key in your code later.

    The 3rd party developer can be added to your developer team, so that they can assign the app to the team and provide visibility to other developers in your org. However, when apps get transferred to new owners, the API subscription keys don't get transferred.

    I hope that helps. Thanks!

  • Thanks @Ben Wong. You've actually taken my question to the next level here! I assumed we should provide subscription keys from our own account, but your reply suggests that we should set up a developer account for our third party, and let them get their own subscription keys. Is that correct?

  • Ben Wong
    Ben Wong Blackbaud Employee
    Tenth Anniversary Kudos 3 Name Dropper Participant

    @John Bird I'm assuming that the 3rd party developer is working on a temporary basis and will transfer the app to you after the project is done and they will no longer be involved. As long as the API subscription key is treated as a sensitive value and can be handled/shared securely, then you can use the org's developer account (e.g. your account) to obtain the subscription and securely provide the keys to the 3rd party dev to use.

    If sharing the keys can't be done securely, then the 3rd party dev can use their own subscription key for development and testing, then provide a way for you to switch it out with your own subscription key when the app is transferred over to you.

    My suggestion for the 3rd party developer to be added to your developer team is just to give them easier access to the app's API configuration e.g. client id, client secret, set redirect URIs, set API scopes, etc. They can have access to control those settings without having their own API subscription i.e. the API subscription controls the quota/rate limits and access to call certain APIs.

Categories