I saw a job posting that genuinely excited me for the first time in a while. The company finds copper deposits using AI. They operate in Zambia, the DRC, Finland, and a dozen other places. The field connectivity problem alone, keeping scientists online at remote sites with limited infrastructure, is the most interesting IT challenge I have heard in thirty years of doing this work.
The posting asked for Okta, Terraform, and infrastructure-as-code experience. I have run infrastructure, identity, and automation for three decades across seven offices and 300 employees. But Okta and Terraform were gaps on paper. So I closed them.
What I Already Understood
The concepts behind these tools were not new to me. I have managed identity and access for decades, just under different names and with different plumbing. SSO is a bouncer with a guest list. The app trusts the bouncer’s word that you are who you say you are, so you only prove yourself once. I knew this. I just had not done it with Okta specifically.
Terraform is declarative infrastructure management. You write files describing what should exist, run apply, and Terraform makes reality match. I have done this with Docker Compose for years. Same philosophy, different target. The Okta provider means your identity configuration lives in code, versioned in Git, reviewable, reproducible. Instead of clicking through an admin console and hoping you remember what you clicked, you have a file that says exactly what exists and why.
Provisioning automation is hire-to-fire logic. Someone joins the company, their accounts get created everywhere with the right access on day one. Someone leaves, everything revokes in minutes. I have built versions of this before using whatever tools were available. The enterprise implementation has a name, SCIM, and a protocol, but the concept is the same one I have been solving for years.
The concepts were not new. The syntax was. That distinction matters.
What I Actually Built
I signed up for an Okta Integrator Free org. It is free, full-featured, and what engineers actually use to prototype. Within a few hours I had Okta wired as the identity provider for my self-hosted infrastructure at scottsbox.com, which runs on Ubuntu 22.04 with Docker behind Cloudflare tunnels.
The Cloudflare Access integration uses OIDC. My services, Nextcloud, Audiobookshelf, Navidrome, Joplin, all sit behind Cloudflare Access. Now instead of each tunnel doing its own identity check, they all route through Okta. One login. Push MFA via Okta Verify. Every subdomain honors the session. The OIDC flow handles the redirect, the token exchange, and the trust relationship cleanly.
I created a group called cloudflare-access-users and configured a groups claim so the token carries group membership. Access control is now group-based. Users in the group get in. Users outside it do not. That is enterprise identity management in miniature.
Then I built the Terraform project. The Okta provider lets you define your entire Okta configuration in code: applications, groups, assignments, policies. I imported the resources I had built manually and brought them under Terraform management. Clean plan, zero drift between code and live configuration. The project lives in a private GitHub repository. Everything declarative, everything versioned.
The n8n workflows came last and were the most satisfying. I run n8n on scottsbox.com already, so the tool was familiar. I built two workflows against the Okta REST API directly. The first is a webhook-triggered provisioning workflow: it receives new hire data, creates the user in Okta, and assigns them to the appropriate group. The second handles offboarding: receives a departing user’s email, looks up their Okta ID, and deactivates the account. Both tested end to end against the live Okta org. Both work.
What Surprised Me
The Cloudflare MFA situation had been quietly annoying me for a while. I kept re-authenticating for different services, which was the whole problem Okta solves. Once I understood that Cloudflare Access is transport-level access control and Okta is the identity layer that sits behind it, the fix was obvious and took an afternoon. I had been living with the friction because I did not have the right vocabulary for what was wrong.
The distinction between SP-initiated and IdP-initiated login flows is subtle but it matters. SP-initiated means the application sends you to the identity provider to authenticate. IdP-initiated means you start at the identity provider and get pushed to the application. Most of my integrations are SP-initiated, which is the simpler and more common flow. Understanding why the difference exists, and when each one is appropriate, is the kind of thing that does not show up in tutorials.
The Terraform state file is either elegant or terrifying depending on how you think about it. It is the source of truth for what Terraform believes exists in the real world. If it drifts from reality, things get interesting. The discipline of treating infrastructure as code only works if you never go around it by clicking things in the console.
What It Means
I have been doing this work for thirty years. In that time I have reverse-engineered a vendor’s black box integration after they went out of business with the source code. I have rebuilt accounting workflows from scratch when the consulting company that built them closed. I have kept servers running without losing a byte of data for twenty-two years. None of those things required Okta or Terraform. They required understanding what a system is supposed to do and building the thing that does it.
The tools change. The thinking does not.
What this weekend confirmed is that the gap between knowing the concepts and knowing the tools is a weekend of focused work. Probably less, if the concepts are solid. I now run Okta in production, manage its configuration in Terraform, and have provisioning automation running against its API. Those sentences are true. I can demo all of it on screen.
The job posting is submitted. The rest is up to the kobolds.