FAQ

What is IdRa?Copy Anchor Link

IdRa is a workforce identity platform. It gives an organization one place to manage its people and how they sign in to apps: single sign-on, MFA, a directory with groups, SCIM provisioning, sign-in policies, device assurance and privileged access to servers and secrets.

Is IdRa hosted or self-hosted?Copy Anchor Link

Hosted IdRa is available today at idra.team. Self-hosting becomes available when the repository is public, which it isn't yet. It will need one Bun process and one Postgres database, on a single replica for now. The self-hosting guide shows what's involved.

Which protocols does IdRa support?Copy Anchor Link

• OpenID Connect and OAuth 2.0: authorization code with PKCE, refresh tokens, client credentials and device authorization, for web, single-page, native and service apps. Clients can authenticate with a client secret or private_key_jwt. Token exchange, JWT bearer, pushed authorization requests, signed request objects and dynamic client registration are also available. See OIDC apps.
• SAML 2.0: IdRa as the identity provider for apps. See SAML apps.
• SCIM 2.0: outbound to apps and inbound from HR systems or other identity providers. See SCIM.
• Signing in through another provider: external OIDC and SAML identity providers. See Identity providers.

Implicit and password grants, SAML Single Logout and assertion encryption for apps, and WS-Federation aren't supported.

Can I migrate from Okta?Copy Anchor Link

Yes, app by app, but IdRa isn't a drop-in replacement, so check the gaps against what you use first. People, groups and apps can be copied across. Passwords and MFA enrollments can't, so everyone sets a new password and enrolls again. Every app needs a new issuer and new client credentials, and sub values change. The migration guide covers cutover and rollback. The Okta importer in the console has only been tested against a simulated Okta API, and federating with a live Okta org hasn't been run.

Do Okta SDKs and tools work with IdRa?Copy Anchor Link

Partly. The /api/v1 API is compatible with core Okta resources and answers 121 of the 815 operations in Okta's Node SDK, as counted on 2026-10-31. In a sample of calls, @okta/okta-sdk-nodejs worked for users, groups, apps, policies, zones, the System Log, event hooks and authorization servers with an SSWS token. @okta/okta-auth-js and @okta/jwt-verifier worked for redirect sign-in and sign-out in a browser, code exchange, and verifying ID tokens and JWT access tokens. signInWithCredentials, session.exists and verifying opaque access tokens don't work, on purpose. SDKs in other languages are untested. The Okta Terraform provider has been run with SSWS tokens for part of its resources, and its OAuth mode doesn't work. See SDK results and the API reference.

What isn't supported?Copy Anchor Link

• Directories: AD or LDAP agents, Desktop SSO, an LDAP interface and RADIUS.
• Devices: native desktop sign-in agents, a device-bound passwordless equivalent to FastPass and a native Verify app. Passkeys are the nearest option.
• Admin: custom roles and resource sets. There are five fixed roles.
• Automation: no-code workflows. Inline hooks can be set up, but no sign-in flow calls them yet.
• Directory model: user types and linked objects.
• API: /idps, /authenticators, /meta/schemas, /org, /domains and most other Okta paths outside the API reference.
• Scale: more than one replica, because some caches and rate limits are per process.
• Language: the UI and emails are English only.

Most vendor integrations, such as MDMs, posture connectors, Twilio and Duo, have only run against fakes or fixtures so far. The full list comes from an audit against Okta.