canonical: https://jentic.com/apis/connect2id.com/connect2id # Connect2id Server API Jentic publishes the only available OpenAPI specification for Connect2id Server API, keeping it validated and agent-ready. Connect2id is a self-hosted OAuth 2.0 and OpenID Connect server that issues tokens, hosts the UserInfo endpoint, and manages OIDC clients and authorization sessions. The 18 endpoints cover the standard OAuth/OIDC surface (authorize, token, userinfo, introspection, revocation, JWKS, discovery, PAR, end session) plus Connect2id-specific management APIs for client registration and authorization sessions. ## For AI agents Issue and introspect OAuth 2.0 / OIDC tokens, register OIDC clients, and manage authorization sessions on a Connect2id server. Useful for agents that automate IdP client onboarding or token validation. ## Scope Does not handle user provisioning, MFA enrollment, or directory sync - use for OAuth 2.0 / OIDC token and client management only. ## Capabilities - Register a new OIDC client and receive its client_id and client_secret - Update OIDC client metadata such as redirect URIs, grant types, and token endpoint auth method - Introspect a bearer token to confirm it is active and read its scopes and subject - Revoke an access or refresh token at the `/token/revoke` endpoint - Fetch the OpenID Connect discovery document and JWKS for signature verification - Create, update, and delete authorization sessions for headless authorization flows - Issue an end-session (logout) request that terminates the user's SSO session ## Use cases ### Headless OIDC Client Provisioning Provision OIDC clients automatically as new services are deployed. The agent calls POST /clients with the client metadata (redirect URIs, grant types, response types) and stores the returned client_id and client_secret in the deployment secret manager. Updates and deletes follow the standard registration endpoints, so client lifecycle stays in lockstep with infrastructure-as-code without operator intervention. Example prompt: Call POST /clients with redirect_uris=[https://app.example.com/callback] and grant_types=[authorization_code, refresh_token], then write the returned client_secret to the secret store. ### Token Introspection in a Resource Gateway When an API gateway receives a request with a bearer token, it calls POST `/token/introspect` on the Connect2id server to confirm the token is active and to extract the subject and scopes for authorization decisions. This is the recommended pattern when stateless JWT validation is not enough and you need real-time revocation behavior. Example prompt: Call POST `/token/introspect` with token= and client credentials, and route the request based on the returned active and scope claims. ### Token Revocation on Sign-Out On user-initiated sign-out, the agent calls POST `/token/revoke` to invalidate the user's refresh token and POST `/session/end` (or the discovered end_session endpoint) to terminate their SSO session. This closes the loop on logout in a way that JWT expiry alone cannot, which is important for shared-device scenarios. Example prompt: Call POST `/token/revoke` with token= followed by GET `/session/end` with id_token_hint= to complete sign-out. ### AI Agent IdP Operations via Jentic Wire Connect2id management into an AI assistant used by platform engineers. The agent searches Jentic for register an oidc client, loads the POST /clients schema, and executes it with the master API token isolated in your Jentic One instance. The same flow covers updates, deletes, and introspection, so the assistant becomes a thin layer over the IdP control plane. Example prompt: Through Jentic, search register an oidc client, load the POST /clients schema, and execute it with redirect_uris and grant_types for the new service. ## Key endpoints | Method | Path | Description | | --- | --- | --- | | POST | `/clients` | Register a new OIDC client | | PUT | `/clients/{clientId}` | Update an OIDC client registration | | DELETE | `/clients/{clientId}` | Delete an OIDC client | | POST | `/token` | Token endpoint (issue access/refresh tokens) | | POST | `/token/introspect` | Token introspection (RFC 7662) | | POST | `/token/revoke` | Token revocation (RFC 7009) | | GET | `/.well-known/openid-configuration` | OpenID Connect Discovery | ## Key resources - **Discovery** — OpenID Connect discovery document and JWKS for client configuration - **Authorization** — Authorization endpoint and Pushed Authorization Request (PAR) endpoint - **Token** — Token issuance, introspection, and revocation - **UserInfo** — OIDC UserInfo endpoint (GET and POST variants) - **Client Registration** — Create, retrieve, update, and delete OIDC clients - **Authorization Sessions** — Connect2id-specific session resource for headless or custom authorization flows - **Session** — End-session (logout) endpoint ## Why Jentic - **Setup:** Wiring the Connect2id Server by hand means supporting both bearer and HTTP basic auth, pointing at your own server hostname rather than a fixed cloud host, and managing OAuth token and client operations yourself. Through Jentic you install once, import the Connect2id Server API from the API Directory, store the credentials once, and your agent calls it. - **Permission scoping:** Connect2id puts the client id in the URL path (`/clients/{clientId}`), so a rule can pin your agent to one registered client: it can read and update that client and nothing else. You choose the operations it may call, so destructive ones like client deletion or token revocation are not included unless you add them. - **Credential handling:** Your Connect2id master token and client secret are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context. - **Discovery method:** Agents search Jentic by intent such as 'register an OAuth client' or 'introspect a token', and Jentic returns the matching Connect2id operation with its input schema so the agent calls the right endpoint without browsing the reference docs. ## Related APIs - **Auth0 Management API** — Auth0 is a hosted identity platform with similar OIDC support - **Okta API** — Okta is a hosted workforce and customer identity platform - **Keycloak Admin API** — Keycloak is the open-source self-hosted IdP from Red Hat ## FAQ ### Why is there no official OpenAPI spec for Connect2id Server API? Connect2id documents the API as standards-based REST endpoints in HTML pages but does not ship a single OpenAPI 3 specification. Jentic generates and maintains this spec so that AI agents and developers can call Connect2id Server API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer. ### What authentication does the Connect2id Server API use? Two schemes are supported: HTTP Bearer with a master API token or an access token for management endpoints, and HTTP Basic with client_id and client_secret for client-authenticated calls (token endpoint, introspection, revocation). Through Jentic the credential is held in the vault and inserted server-side. ### Can I introspect a bearer token through this API? Yes. POST `/token/introspect` implements RFC 7662 and returns whether the token is active along with its scope, sub, exp, and other claims. This is the recommended endpoint for resource servers that need real-time revocation checks rather than relying on JWT expiry alone. ### Can I dynamically register OIDC clients? Yes. POST /clients implements OIDC dynamic client registration. The response returns a client_id and (for confidential clients) a client_secret, plus a registration_access_token that can be used with PUT and DELETE on `/clients/{clientId}` for subsequent updates. ### Where do I get the JWKS for token verification? GET /jwks.json returns the server's public JSON Web Key Set, which clients use to verify access token and ID token signatures locally. The JWKS URL is also published in the discovery document at GET /.well-known/openid-configuration. ### How do I provision an OIDC client through Jentic? Run pip install jentic, then await client.search('register an oidc client'), load the matching operation schema, and execute it. The underlying call is POST /clients with the client metadata you supply at runtime. ### Can I limit what my agent is allowed to do with the Connect2id Server API? Yes. Because you run Jentic One yourself, your own rules decide which Connect2id operations and credentials the agent may use. Since Connect2id puts the client id in the URL path at `/clients/{clientId}`, you can pin the agent to a single registered client so it only reads and updates that client and nothing else. You choose the exact operations it may call, so destructive ones like DELETE `/clients/{clientId}` or POST `/token/revoke` stay out of reach unless you add them.