Hi! Apologies if this question has already been answered here and I missed it, but I had a question about what the recommendation is for integrating SSO with production vs. dev/test/staging environments.
I’ve had some trouble getting an understanding of what Okta recommends here. Should we be using the Okta sandbox? Does it offer the same security as the production okta account? Or, should we potentially have two clients set up–one for production and one for the other environments. What have others done? We want non-prod environments to be as secure as the production environment.
both .oktapreview.com and .okta.com are equally secure preview have some limitations. But you can always have your non-prod environments created in okta.com
Great, thanks for this information! If it’s appropriate to set up non-prod environments with .okta.com rather than the sandbox, would the best way to do that be to have two clients (one for prod and one for non-prod environments)? I assume we want to avoid having both prod and non-prod environments using the same client secret.
Sure, you can have different client apps in different environments. Would be a terrible idea to accidentally leak production secrets during development/testing.
Just keep in mind that .oktapreview.com is free, though you’d have to pay for .okta.com. So think twice
Hi! I’m a bit confused–if my organization already pays for .okta.com, would there be an extra cost for integrating an additional client? I didn’t think there was additional charges for adding clients.
A reason I’m interested in using .okta.com for non-prod environments is because we would need to load our users into the sandbox and users would need different sandbox credentials. But if that’s the best practice, I definitely want to follow the best practice.
I think we maybe talking about different things. Here is the scheme I mentioned:
you have 2 okta orgs, one in .okta.com as your production and in .oktapreview.com as your non-production
you need to clarify what you mean as “client”, if it’s an application inside an okta org, then you don’t have to pay extra, you can have as many of those in your prod as you need, not sure if there is a limit in preview though
I would not necessarily say it’s “best” practice. It’s just a one of applicable models. As I said, there might be some limitations in .oktapreview.com for a number of things you can create. Better to consult okta support.
I’ve worked with clients who paid for extra .okta.com organization and had it as their TEST/UAT environment
Hi! Yes, my use of “client” was confusing. The schema I’m interested in is having two applications on a single .okta.com organization, one for my site’s production environment and one for my site’s test environment.
Can you confirm this is an appropriate model?
I really appreciate your responses here–this has been so helpful!
Hi Alina, did you solve this? did you need to create two separate OKTA admin accounts, or were you able to create a user partition within one admin account for dev vs. prod?
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!
I have a similar question but I am using a single page app (React) with a PKCE flow so there is no client secret. There are client ids but from what I understand it’s fine to have these public. My question is we have a dev, staging and production environment so is it ok to just have one single Okta app and add 3 re-direct URIs? For example:
Whoops, I realize i made a mistake in my earlier reply where I said redirect_uri instead of authorization server base url. I corrected the post.
I don’t know much about the PKCE flow, but my instinct would be to avoid using the same client id for production and test environments even though it’s public. But I’ve only researched implementing the authorization code flow since we have a server.
preview have some limitations. But you can always have your non-prod environments created in