IDP discovery and domain ownership validation

I am building an application where we want to allow our users to sign in using their own IDPs, and we’re using okta.

We don’t want our users to have to:

  • Create all their organization users manually
  • Be dependent on SCIM (or any other synchronization)
  • Maintain many users that most of them will probably not use our system

Since our user ids are email addresses and all of our customers are enterprises, we want to map domains to IDPs.

Meaning that if is a customer of ours, then all email addresses like or should be handled by their IDP. the thing is we want to make sure that they own the domain before adding their IDP to our discovery logic.

We were thinking about doing a DNS validation using a TXT record, but we aren’t sure that this is the correct practice for this.

So finally my questions are:

  1. Is there a common practice for this?
  2. Are there downsides to the DNS record validation method?
  3. Are there any caveats we should be aware of? should we re-validate the ownership periodically?

Hey tomer-amir, I’ve seen the TXT record approach with a number of SaaS providers (including Okta if you’ve setup a custom domain). So it seems standard? Usually a long, random string.

Can’t answer the other questions unfortunately! I don’t know enough about DNS :slight_smile:

The broader trade-off with just in time provisioning to potentially be aware of (or make your users aware of) is that there will always be an active Okta account in your Okta org. A savvy user could potentially set a password in your Okta for their account (if the user knows what they’re doing and knows you’re using Okta). When a User terminates employment with their organisation, they can’t login via their IdP, but there is still an active account for them in your Okta.

You may still need to consider how users are deprovisioned/deactivated. SCIM is nice, open-standards way to do this automatically. You could also require your User’s organisation to have a manual cleanup process for a low tech/cheap/unsexy approach.

You could also look at prevention by setting policy to prevent users logging into your Okta org’s dashboard / accessing user management or a detection approach - you may want to monitor for set password / password reset events.

Cheers, Adrian

Thanks for your answer!
Just one follow-up question… can I block users using IDPs to set or use a password at all in my okta org?

I don’t believe so. Some options/ideas:

  • Monitor the system log for password set events for federated users and non idp-related. If you forward your system logs to a SIEM or log aggregator you could wired some rules there and have alerts.
  • Have a policy to purge inactive users (this could be done manually, scripted or you could write a process/service).
  • Implement a SCIM interface / API so customers can de-provision their users automatically.
  • Provide a delegate administration user interface (cut down UI) for a customer representative to manually deprovation their users. This could be done with Okta roles and the Okta UI, or you could build a customer portal.
  • Do nothing. Know the risk is there and accept it.