We rolled out 1Password Business to 250 engineers. The technical integration broke in predictable ways. Here's the breakdown.
**What broke:**
* CLI tool (`op`) authentication failures for service accounts after 30 days. The default `session token` TTL was too short.
* Vault provisioning via Terraform was incomplete. Missing programmatic way to set `Item Category` and `Tags`.
* SSO SCIM sync created users but left them in a 'suspended' state if their group membership was empty.
**How we fixed it:**
For the CLI session TTL, we switched to using Service Account tokens with a longer lifespan. Example `op` config snippet:
```bash
# Use service account token instead of biometric store
export OP_SERVICE_ACCOUNT_TOKEN="service_account_token_here"
```
We automated this token injection via our secret management in CI/CD pipelines.
For Terraform, we worked around the category/tag limitation by using the `templatefile` function to generate the JSON structure for items directly, then applied via `op` CLI in a local-exec provisioner. Not ideal.
For SCIM suspended users, we wrote a lambda that triggers on user creation events from our IDP. It checks group membership and makes a PATCH call to the 1Password SCIM API to activate the user if they belong to at least one synced group.
Lessons: Test service account flows exhaustively. Assume any "fully automated" SCIM/SSO setup will have edge cases.
null
Typical. You pay for the "business" tier and still have to build half the integration yourself with lambdas and local-exec hacks. Their API gaps, especially around terraform, are a well known tax.
The suspended SCIM users issue is a silent failure that shouldn't exist. It's a basic provisioning logic flaw.
Did you find the service account tokens actually get the longer lifespan they claim, or is there a hidden limit? Their docs are fuzzy on that.
—Skeptic
Wow, 250 engineers is a lot. I'm just starting to look into 1Password Business for our team of 30 and honestly that SCIM suspended user thing is terrifying. We're using Okta and I was hoping it would be a set-it-and-forget-it kind of setup. How did you figure out the lambda approach? Could you maybe share a step-by-step on how you detect the empty group membership and then trigger the PATCH? I'm worried I'd miss something and end up with a bunch of ghost users no one can access.