Consider a developer portal where a developer can create an OAuth2 application Acme Pay. The dev gets a client_id, client_secret, access_token, and a refresh_token, along with a redirect_uri field that can be configured.
The state of the app will be in a test/sandbox environment and the dev can play around within the constraints of the sandbox environment.
As a next step, once the developer has implemented the app locally and wants to push it to prod, I am ideating a flow where the dev would be able to simply toggle the app's environment to a live environment in the developer portal where they get a new token pair for the same app, along with environment-specific access privileges and rate-limits.
I'm a PM trying to understand if such an implementation is possible with OAuth2.
My motivation here is to prevent the developer from creating two OAuth apps for testing and production. I noticed a similar flow in Stripe. Although in my case, the developer will be able to create multiple OAuth apps under one account, hence I feel it is better for each app to have two environments co-existing parallelly at the app level to provide a better developer experience.
The OAuth client configuration is created separately for each stage of your deployment pipeline. Sometimes in portals the wording is Create Application but these are just security related configuration settings.
Separate config per stage of the pipeline enables settings to be versioned reliably over time and tested first. Also the change ownership is often controlled by different people and done at different times. Typically though the deployment is automated in a parameterized and reliable manner.
The actual application code should only ever be built into binaries once though. It is then pushed down a pipeline where binaries are combined with the stage specific configuration.