Platform / API access management
Decide which apps can call which APIs, in the same place.
Authorization servers, custom scopes and access policies for your own APIs, built on the same identity data and System Log.
{
"iss": "https://acme.idra.team/api/auth",
"aud": "https://api.example.com",
"scope": "invoices:read",
"sub": "user_8f3a",
"exp": 1793404800
}Example values. Scopes, audience and lifetime come from your authorization server. Check signatures against its JWKS.
Authorization servers for your APIs
Describe each API as a resource with its own audience, scopes, claims and token lifetime, and preview a token before you ship.
- Custom scopes and static custom claims
- Access policies by client, group, grant and scope
- Token preview in the console
The standard endpoints
Clients and gateways that understand OAuth 2.1 work without IdRa-specific code.
- Discovery, JWKS, userinfo, introspection and revocation
- Authorization code with PKCE (S256), client credentials, refresh and device code
- Self-run OpenID conformance suite, Basic OP plan: 26 of 35 modules passed, 0 failed, not a formal certification
Machine access you can see
Service apps use client credentials, admin tokens act with their owner’s current role, and every grant is covered by rate limits.
- Admin API tokens with last-used tracking
- Manual signing-key rotation
- Rate-limit headers on the management API
Standards it speaks
- OAuth 2.1
- RFC 7662 introspection
- RFC 7009 revocation
- JWKS
Not here yet
- Token exchange, PAR, JAR and dynamic client registration
- Re-checking API access policies on refresh and device-code grants
- Token and SAML inline hooks
- Separate signing keys per authorization server, and claims built from expressions
We’d rather you read this now than find it in a pilot. See the full comparison.
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.