Built to fit where Okta already is.
Your apps speak standards, and your scripts speak Okta’s API. IdRa implements both, and this page shows how far each one goes.
curl -H "Authorization: SSWS $TOKEN" \
"https://acme.idra.team/api/v1/users\
?search=profile.email%20sw%20%22ana%22&limit=2"
HTTP/2 200
Link: <…/api/v1/users?search=…&limit=2>; rel="self"
X-Rate-Limit-Limit: 600
X-Rate-Limit-Remaining: 599
X-Rate-Limit-Reset: …Standards
If an app works with Okta through one of these, it should connect to IdRa the same way, within the limits listed.
| Standard | Status | What works | Not yet |
|---|---|---|---|
| SAML 2.0 | Included | SP- and IdP-initiated sign-on as an identity provider, metadata, attribute statements. Tested with SimpleSAMLphp. | Single Logout, encrypted assertions, signed AuthnRequest checks |
| OpenID Connect, OAuth 2.1 | Included | Code + PKCE, refresh, client credentials, device code, discovery, userinfo, introspection, revocation, back-channel logout. OpenID conformance suite, self-run: 26 of 35 modules passed, 0 failed. | Native apps, private_key_jwt, PAR, JAR |
| SCIM 2.0 | Partial | Inbound server for users, with PATCH and deprovisioning. Outbound client with create, update, deactivate, reactivate and group push. | Rich filters on inbound, account delete on outbound |
| WebAuthn and passkeys | Included | Sign-in and step-up. Passkeys are the factor IdRa counts as phishing-resistant. | AAGUID allow-lists and attestation |
| Shared Signals (SSF, CAEP, RISC) | Included | Transmitter by push (RFC 8935) or poll (RFC 8936). Receiver accepts CAEP, RISC and Okta’s risk events. Not yet run against live partners. | Polling as a receiver, stream management as a client |
| Global Token Revocation | Partial | Calls draft-parecki-oauth-global-token-revocation endpoints during Universal Logout. | The draft’s signed-JWT client authentication: IdRa sends a Bearer token |
| TOTP | Included | Any standard authenticator app. |
The Okta-compatible API
Under /api/v1, IdRa answers 118 of the 815 operations in Okta’s Node SDK, counted in our October 2026 audit. The ones it has follow Okta’s authentication, cursor paging, error bodies and rate-limit headers, and its tests drive them with @okta/okta-sdk-nodejs.
| Resource | Endpoints | Worth knowing |
|---|---|---|
| Users | /users, lifecycle, revoke sessions, list and delete factors, roles, groups, appLinks | Every user has the default type. The login is the email. No linked objects. |
| Groups | /groups, members, apps | Up to 1,000 per page. |
| Group rules | /groups/rules, lifecycle | A subset of the Expression Language. One target group per rule. |
| Apps | /apps, lifecycle, users, groups, policies | Bookmark, OIDC web, browser and service, SAML 2.0. No native or implicit. |
| Authorization servers | /authorizationServers, scopes, claims, policies, rules | One access policy per server. Static claims. |
| Policies | /policies for sign-on, access and password types, with rules | Only password policies can be created with POST. Other types list empty. |
| Network zones | /zones | IP and dynamic zones. Always active. |
| Event hooks | /eventHooks, lifecycle and verify | Same verification challenge and body. No filter. |
| System Log | /logs | Filter, search and polling. Some fields are placeholders. |
| User risk | /users/{id}/risk | HIGH and LOW. |
Most unsupported filters and conditions are rejected with an error rather than ignored. The rest of the Okta API, including IdPs, authenticators, devices and brands, isn’t there yet.
Moving from Okta, without a big bang
There’s no one-click migrator. This is the path the product supports today, and you can run both side by side while you do it.
Look at what you have
Connect the Okta posture connector to inventory accounts, admins and MFA gaps in your Okta org.
Federate first
Add Okta as an OIDC or SAML identity provider so people keep signing in there and get IdRa accounts just in time. An identity provider links existing active people on its domains at first sign-in, except admins, who keep their own IdRa sign-in.
Bring the rest across
Import a CSV or push users over SCIM, then rebuild groups and rules. Scripts can do part of this through
/api/v1.Move apps one at a time
Point each SAML or OIDC app at its new IdRa issuer and metadata, then test it with a small group.
Switch sign-in over
Have people enroll passkeys or other factors in IdRa, then retire the federation.
Common compatibility questions
Can I use Okta’s Terraform provider?
Not proven yet. It hasn’t been run against IdRa, so treat it as untested. It’s on the roadmap.
Do passwords and factors move across?
No. IdRa has no importer for them. People set a password and enroll their factors again when they activate, or keep signing in through Okta while you federate.
Do integrations built for Okta’s security-events endpoint work?
After a change: a partner integration has to send to /ssf/events rather than Okta’s path.
Which tokens does the API accept?
SSWS tokens from Security → API → Tokens. They act with their admin’s current role. OAuth-scoped tokens are on the roadmap.
Create your organization.
Pick an address and confirm your email, then sign in as its first admin. A setup wizard takes you through the rest.