I’ve seen it suggested in a few official Okta docs that developers should add http://localhost:somePort to their login redirect URIs.
I haven’t thought this all the way through, but this smells funny to me. Suppose I work for the Acme Corporation, and I’ve set up my HR app with Okta. For the app’s dev environment, I’ve added http://localhost:3434 to my login redirect URIs config. Since any machine can call itself localhost, isn’t there some risk that a nefarious actor could masquerade behind the legitimacy of the Acme Corp logo and login screen? Even though the credentials themselves wouldn’t be compromised (because they only ever pass through Okta’s hands), couldn’t the Acme/Okta login give users a false sense of security about the authenticity of the site they are using, resulting in employees being fooled into providing sensitive information to an outsider?
If there are not security implications around the redirect URIs, why does the setting exist at all? Why not allow any site which has the Okta client ID to redirect?
Thanks for engaging in this thought experiment with me!
You should only use localhost when developing locally on your machine. For production, you should use a full domain with HTTPS. This guide specifies the things you’ll need for production.
Thanks for your response,@mraible, but I’m really hoping to do a deep dive on what security issues such a configuration might raise.
Of course a production deployment of the Acme HR app would live at a FQDN like https://hr.acme.corp, but development never stops, does it? Developers will always have an instance going at http://localhost:3434. That means devs will either have to:
Leave localhost in the redirect config, and authenticate with Okta even when accessing their local instance (annoying but not the worst thing, if there’s no added risk).
Take localhost out of the redirect config to mitigate risk and add some mechanism (likely a feature flag) to their app to disable the Okta integration in some contexts.
Some other option I’m not thinking of?
Most of the mentions of localhost that I’ve seen are in “quick start”-type docs. In that context, the configuration makes plenty of sense, but advice given in “quick start” documentation is often intentionally oversimplified and not suitable once an app has gone to production. It’s not clear to me whether the advice given around localhost falls into this category or not.
We recommend developers have their own Okta developer account when developing an app. I don’t think it’s a good idea to use your production org for development purposes.
Your CORS issue sounds like an application issue rather than an Okta issue per se. Here’s a good resource for most general “how do I enable CORS on platform X?” questions. There are also several Okta-specific examples in the official documentation – select your tech from the “Instructions for” dropdown for information tailored to your use case.
It does seem like poor practice to leave localhost in production config – and it might be a nice improvement to the pre-launch checklist to advise people to remove that – but using a separate org for development renders my “but, really, are there security implications?” question moot.