That’s how it starts though. If everything is provided at deploy and nothing is ever embedded in source code there’s no way you can end up in this situation.
In some industries it’s also an audit or legal requirement that developers not have access to production credentials, so there’s no other way to reasonably handle that.
Edit: also, rebuilding your source because an API key changed... no thanks.
> Add an OAuth-style negotiation for the key as the first startup process.
How does this possibly work? You must have some “bootstrap key” that you would use to fetch the API key. You’re going to ship something in the app that says “hey, I’m really your app” or else you’re doing to allow anyone to fetch your API key. All you can do is obfuscate the process of getting the API key. You cannot actually keep it secret when you need clients to have access to it.
Case in point: valid user credentials and it doesn’t matter what app is trying to authenticate. Issue a different key for every user (or every user per login or device) and your problem is solved.
Even if your app doesn’t require any login there’s no reason you shouldn’t go through the same process. Every device gets its own key and then you apply limits to it...
You need an api key if you show Google Maps in your app. The api key allows your app, running on the users device, to get the map tiles. Is it possible to do that without the users device having access to the key? No. Does that require user login? No. Does ‘OAuth style negotiation’ have anything to do with that? No. Is it security? No. Can you change how Google Maps works? No.
