# One identity for every API, application, service, and agent
Create a persistent identity for every actor. Connect authentication methods and credentials to a single Principal, enforce access consistently, and trace activity back to who or what performed it.
## One identity across every interaction
- *
Map every credential back to one Principal, so API keys, OAuth tokens, mTLS certs, and service accounts all resolve to the same identity even as auth methods change.
- *
Tie all activity to that identity, connecting requests, resource access, policy decisions, analytics, and audit events to a single Principal.
- *
Enrich identity with context and associate teams, business units, environments, and other metadata with the Principal for policy and attribution.
## Give agents access without giving them credentials
- *
Keep credentials out of agents and store downstream credentials centrally instead of embedding them in agent implementations.
- *
Broker credentials at runtime by providing the appropriate OAuth token, API key, service account, or other credential when access is needed.
- *
Shrink the blast radius, revoking or rotating access centrally instead of hunting down credentials spread across agents and apps.
## Native gateway and event enforcement
- *
Enforce identity through native plugins, including OpenID Connect, OAuth 2.0 Introspection, and Upstream OAuth, out of the box.
- *
Extend one security boundary across every gateway, covering Kong AI, API, and Event Gateways.
- *
Govern every workload with the same architecture, from traditional REST APIs to ephemeral AI agents and event streams.
## Pass-through identity enrichment
- *
Enhance and layer over your existing identity infrastructure rather than forcing a complex forklift replacement.
- *
Run real-time directory lookups at runtime, even when third-party IdPs or TLS certificates handle the initial handshake.
- *
Pull metadata into policy on the fly, injecting UUIDs, team ownership, and environment tags directly into gateway policy expressions.
## Automated credential lifecycle management
- *
Username and password authentication paths feature built-in rotation, revert, and commit workflows managed directly within the control plane.
- *
This architecture enforces robust cryptographic hygiene across your workloads without relying on external credential managers or manual support tickets.
- *
You can seamlessly roll out new credentials to active workloads, verify their stability, and deprecate old keys safely without risking operational downtime.
## Universal multi-auth consolidation
- *
Unify completely disparate authentication strategies into a single, central principal identity record.
- *
The system automatically associates traffic from API Keys, Basic Auth, Kong OAuth, third-party IdPs, and mutual TLS certificates back to the same unique profile.
- *
This gives platform teams a cohesive ownership record and a clear source of truth for tracking every authentication pattern used across the entire estate.
## One identity layer, from first token to audit trail
From real-time visibility to compliance-ready logs, built into Konnect.
### 01 / Principal-drive analytics
See how every team and workload consumes resources, filtered by Principal Identity across your whole estate.
### 02 / Dynamic claim templating
Generate JWT claims at runtime, inheriting directory attributes to power downstream authorization.
## Related products
## Resources
## FAQs
Do I need a third-party identity provider to use Kong Identity?
No. Kong Identity is a native, Konnect-hosted OAuth 2.0 authorization server with OpenID Connect, so you can issue and validate tokens for machine clients without standing up or paying for a separate IdP. It also interoperates with your existing IdP when you have one.
What's a "principal"?
A principal is any entity — machine, agent, process, or human — that authenticates to a Kong product. One principal can hold multiple credential types (OAuth clients, API keys, username/passwords) and carries metadata that drives gateway policy decisions.
Does Kong Identity work across API, event, and AI traffic?
Yes. The same principals and directories authenticate across Kong Gateway, Event Gateway, and Dev Portal, so API, Kafka/event, and agent traffic are governed from one identity layer.
How is this different from just using Kong's OAuth plugins?
The plugins (OIDC, OAuth 2.0 Introspection, Upstream OAuth) validate and pass tokens; Kong Identity issues them. It adds the authorization server, principals directory, dynamic claim templates, and self-service registration that those plugins consume.