Okta alternatives that are not Azure AD or OneLogin

We're trying out Keycloak with the Red Hat SSO operator in our Kubernetes cluster. Their Terraform provider is community-supported, but I've managed to define realms and OIDC clients as code. The API is pretty solid for automation.

SCIM support was tricky though. Did you find any cloud-native providers with good SCIM and a strong IaC story? I'm also worried about the operational overhead of self-hosting something like Keycloak.

That's a cool setup. I hadn't considered running a Keycloak operator myself. I'm also looking at cloud-native options for that same reason.

I was curious about the SCIM part. Did you have to use a separate plugin for it, or was it just complex to configure?

Yeah, the SCIM part required a separate plugin for us. The Keycloak SCIM SP1 plugin does the job, but you have to build and deploy it yourself into the container. It adds another layer to manage for updates.

For a cloud-native alternative with strong SCIM out of the box, we've had good results with Auth0's Terraform provider. Their SCIM configuration is a first-class citizen in the API. The pricing can get steep if you have a lot of custom rules, but their IaC story is solid. Might be worth a quick POC.

Yeah, the per-feature module pricing can really sneak up on you. For a modern, API-first platform, I'd take a close look at FusionAuth. Their Terraform provider is solid and they treat SCIM as a core feature, not an add-on.

Here's a snippet from our config for an OIDC app:
```hcl
resource "fusionauth_application" "gitlab" {
name = "GitLab Production"
oauth_configuration {
enabled_grants = ["authorization_code", "refresh_token"]
redirect_uris = ["https://gitlab.example.com/users/auth/oidc/callback"]
}
}
```
The API lets you manage everything - applications, users, registrations - without touching the UI. Their pricing is per monthly active user, which stayed predictable as we scaled up. Might fit that developer-focused angle you're after.

That's a good starting list. I'd caution that the "reasonable pricing per user" can be tricky, as many providers now count MAUs (monthly active users) in their pricing models. That can be great for predictability, but if you have a lot of service accounts or bots authenticating via OIDC, they can quietly inflate your count. Always check what they consider an "active user" before committing to a POC.

I can share our team's experience with the Terraform provider for Auth0, specifically on your IaC point. While user1079's warning about MAUs is valid for service accounts, we've found the provider quite complete for application definitions. Here's a specific snippet for a Jenkins SAML app, which handles the attribute mapping we needed.

```hcl
resource "auth0_client" "jenkins_prod" {
name = "Jenkins Production"
app_type = "regular_web"
oidc_conformant = false

saml_configuration {
audience = "https://jenkins.internal.example.com"
recipient = "https://jenkins.internal.example.com/security/saml/consume"
destination = "https://jenkins.internal.example.com/security/saml/consume"
mapping = {
email = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
name = "http://schemas.microsoft.com/identity/claims/displayname"
}
create_upn_claim = false
passthrough_claims_with_no_mapping = false
}
}
```

The provider covers SAML, OIDC, actions, rules, and branding. The main caveat we hit is that some newer platform features, like Organizations, lag in the Terraform provider by a few months, so you occasionally need a mix of API calls and Terraform for edge cases.

That lag you mentioned is the real kicker. Everyone's Terraform provider is "complete" until you need the shiny new feature they just launched. Then you're stuck with manual config or a patchwork of API calls that break your drift detection.

Also, let's be honest about Auth0's "MAU" counting for service accounts. Their docs are a maze on that. I've seen teams get burned thinking a service account doing a daily cron auth was one MAU, not thirty. 😒

Ever check their support SLA for non-enterprise plans? Good luck getting a fix for that provider lag.

We looked at Auth0's Terraform provider for exactly that IaC requirement. While the API's decent, I've noticed a real lag between new UI features being available and the provider supporting them. Makes drift detection a pain.

Have you considered a cloud-hosted Keycloak service? I know user408 mentioned self-hosting, but some managed offerings (like from a cloud provider) might give you that full API control with less ops headache than running the operator yourself.

That lag is a universal issue, not just an Auth0 problem. Terraform support is a key feature for any vendor calling themselves "API-first" now. The real test is how long that lag is and what their commitment looks like.

Managed Keycloak is a solid idea to check the IaC box without the operational burden. But make sure you're not just trading one ops headache for another - you're still on the hook for the custom plugin situation for SCIM that user480 mentioned.

Ping the sales engineer and ask directly: "Show me your Terraform provider's GitHub release cadence for the last year. How many days, on average, between a UI feature launch and provider support?" Their answer, or lack of one, tells you everything.

That's a great point about SCIM being first-class in the Auth0 API. It's a huge time saver not having to manage a custom plugin layer. We found the same benefit.

But your warning about pricing with custom rules is spot on. That's where their consumption model can really bite you. We had a project where just a few extra complex attribute mappings pushed us into a higher bracket. It's a trade-off: amazing developer experience, but you need to forecast those rule complexities carefully.

Have you looked at how they handle rule versioning or rollbacks in their Terraform setup? That was another piece we had to figure out manually.

Rule versioning in their Terraform provider is non-existent. You manage rules as separate resources, so rollback means reverting your state file and hoping the old rule ID still works. We scripted our own versioning by tagging rule resources with a Git commit SHA in the description.

And yes, the pricing bite is real. Those complex mappings are often the entire point of using a rule, but they're what pushes you over. We started treating Auth0 rules like premium infrastructure - each one needs a cost-benefit review.

Asking a sales engineer for GitHub stats is a fantasy. Their metrics are about quota, not commit history. They'll send you a pre-approved slide deck that shows "commitment" with zero actual data.

Managed Keycloak just outsources the server rack, not the plugin maintenance. You're still building and patching that SCIM bridge yourself, which is the real time sink. The ops headache moves from infrastructure to dependency management.