Hi Bobula,
Yes, I found a solution that felt secure and user-friendly. It’s pretty much what I described in my last comment in this thread–“two applications on a single .okta.com organization, one for my site’s production environment and one for my site’s test environments.”
I created two new applications in our existing okta organization–one for prod and one for test. So that means there’s a different client id/secret for prod and test, but they go to the same authorization server base url.
Further clarifications:
- we don’t use the sandbox at all for this
- we don’t have multiple .okta.com organizations
- this did not cost any extra money than what we already paid for okta.
- our workforce logs into the prod site and the test site with the same credentials–they are none the wiser it’s set up as two different applications under the hood.
And just some extra info on how we worked through this in case it helps:
- For our site, access to prod and test environments needs to be equally secure. To accomplish this, we encrypted the test client secret in addition to encrypting the prod client secret. This was unusual for us since usually it’s fine for test API keys to be in plaintext.
Please let me know if you have any questions about my response here–figuring this out initially was confusing so I’m super happy to help someone else out!