I am developing a reactjs app which uses Okta and have just added “sign out” functionality. In order to enable CORS I had to add my http://localhost:4000 url to the “Trusted Origins” list? Just wondering if this it ok from a security point of view?
Yes, it’s fine. It’s also recommended for local development.
1 Like
Great . The only thing I was thinking was that someone else could run their own app on http://localhost:4000, use my client id since it’s easily seen in the browser. But then again they’d still have to be able to sign in so that should be enough protection.
I often think of a client ID like a license plate on a vehicle. It’s just an identifier and can’t really be used maliciously. A client secret is more like a social security number. You don’t want to expose it. If you do accidentally, I recommend your delete your app.
3 Likes
Thank you! It’s less the client id but moreso that they could gain access to my app by running their own app on the same domain http://localhost:4000 and perhaps run malicious code. Like I said though I suppose they’d need to also have log in credentials too?
While they could certainly try to make requests against your auth server, passing the CORS policy, they aren’t able to authenticate without client_id, credentials, etc.
Obviously don’t use it in prod
Funny story: The one time I’ve felt localhost callback was really a problem is when we had an app built by a 3rd party who didn’t really know what they were doing. They had a distributed team with limited oversight and insisted they needed localhost as a callback URI to support the app - testing/debugging in prod. That mixed with some test credentials they probably stored insecurely and varying expertise of developers gave me some heart palpatations. Business accepted the risk, so ¯_(ツ)_/¯
2 Likes
Thanks @abole. We have 3 app instances under our Okta account: dev, staging and prod. If I add http://localhost:4000 as a trusted origin, do you know if that is shared across all app instances?
2 Likes
So you reckon it’s ok to have http://localhost:4000 in here since this list would also be used in prod?
I wouldn’t recommend localhost in prod @ReturnOfTheMac. It knocks out one layer of security protection for production. YMMV.
1 Like
Perhaps try to avoid testing in production - have a non-prod Okta org (setup a free one at developer.okta.com) or request an Okta Preview org which also lets you kick the tyres on new features.
Part of the app deployment process to prod should configure the app in the Okta prod instance including callback URIs which should be your proper domain. We’re using Terraform to help automate this config as part of our CI/CD pipeline (Other smarter folks in the team do this for us - I haven’t yet done it myself).
If testing in prod for you is more ‘monitoring’ perhaps it’s worth looking into some sort of test harness running synthetic transactions like Selenium or similar. So you’re monitoring the ‘true’ user experience, this should be running the app just like the user would with the same call-back URIs.
1 Like
Perhaps I’m misunderstanding something. We have 3 app integrations: dev, staging and prod. This means 3 separate issuer urls, client ids and callback uris. We swap these out depending on the environment you’re in. We use the dev okta app info when developing locally. However, as far as I know the “Trusted Origins” list is shared across all app instances, meaning if I add http://localhost:4000 as a trusted origin for the purposes of being able to test and develop locally, that is also seen as a trusted origin in all 3 app instances right? Or is it possible to only set the trusted origin per app instance?
If you only have the one Okta organisation then yes you’re are correct - the CORS URL will be shared and available for all apps.
This is one of the weakness (depending on how you look at it) in having a single Okta org with 3 app definitions representing each environment.
Alternatively you could have:
Okta dev org - your dev org with your dev app config
Okta test org - your test org with your test app config
Okta prod org - your prod org with your prod app config
The draw back here is maintaining 3 orgs and keeping them somewhat consistent so they’re representative. You tend to get better security and user data quality outcomes keeping them separate.
That said both models work. I’ve worked with some customers where we modelled all 3 environments in a single org and others where we have discrete okta orgs for each environment.
1 Like
Perfect answer, thanks for sticking with me 
1 Like
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.