What Is OIDC Endpoints? Definition & Examples

OIDC endpoints are the web addresses an application uses to start login, verify identity, and obtain tokens from an OpenID Connect provider. In practice, they expose standard functions such as authorization, token exchange, userinfo, and metadata discovery, enabling secure federated authentication across human users, services, and agents.

OIDC endpoints and what they do

OIDC endpoints are the public protocol entry points that let an application begin authentication, redirect the user or client, and exchange authorization output for tokens. Their role is to turn OpenID Connect from a specification into a working login flow.

Because these endpoints sit on the trust boundary between the application and the identity provider, they are part of the authentication surface even when the application never sees a password directly. The important question is not just whether the URL exists, but whether the application is using the right issuer and endpoint set for the trust relationship it is trying to establish.

The main OIDC endpoint types

In practice, OIDC deployments revolve around a small set of standard endpoint functions. The authorization endpoint starts the sign-in request, the token endpoint exchanges an authorization result for tokens, the userinfo endpoint returns profile claims when permitted, and the discovery document advertises the provider metadata so clients can configure themselves safely.

These endpoints matter because they divide responsibility across the authentication flow. The application should not hardcode assumptions about token formats, keys, or issuer details if discovery is available, and the provider should keep each endpoint tightly aligned with its declared metadata and signing material.

How OIDC endpoints support federated access

OIDC endpoints are what make federated login usable across browsers, native apps, service-to-service integrations, and, increasingly, automated systems. The same protocol can support interactive user sign-in and non-interactive flows, but the security meaning changes with the client type and the token audience.

For practitioners, that means endpoint usage should always be read together with client registration, redirect handling, scopes, token audience, and session handling. The protocol may look uniform, but a browser-based login, a backend service, and an automated agent do not present the same risk profile or trust assumptions.

Security implications of endpoint trust

OIDC endpoint mistakes usually show up as trust failures rather than simple configuration errors. If a client trusts the wrong issuer, accepts forged metadata, mishandles redirect URIs, or sends secrets to the wrong token endpoint, the result can be token theft, login abuse, or impersonation.

Because the endpoints are standardized, attackers often target the implementation gaps around them, not the standard itself. That includes phishing-style consent abuse, token interception, metadata manipulation, and misbinding between the endpoint set and the application that is supposed to use it.

Risk and Threat Considerations

OIDC endpoints are attractive targets because they concentrate authentication trust, token issuance, and metadata discovery in a small number of public URLs. If those URLs are misconfigured, spoofed, or paired with weak client validation, an attacker can turn normal login traffic into a path for token theft or account takeover.

Failure mechanism: The application accepts endpoint data or tokens from an untrusted source, or it sends a client secret, authorization response, or session-bearing request to the wrong endpoint.

Impact: An attacker may gain unauthorized access, mint or replay tokens, impersonate a user or service, or persist inside the federated login path even after the initial abuse is noticed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	Digital Identity Guidelines	OIDC endpoints implement federated authentication and token-based identity assurance.
Recommendation — Align issuer, authenticator, and federation settings with digital identity guidance.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	OIDC endpoints rely on token and secret handling that must be protected across the auth flow.
	IA-2 — Identification and Authentication (Organizational Users)	OIDC endpoints are a primary mechanism for authenticating users through federation.
Recommendation — Protect and rotate client secrets, tokens, and related authenticators. Use federated authentication controls that verify users through trusted identity providers.
OWASP ASVS	V10 — OAuth and OIDC	OIDC endpoints are a core OpenID Connect integration surface covered by ASVS.
Recommendation — Verify OIDC flows, redirect handling, and token validation against OIDC requirements.
OWASP API Security Top 10	API2 — Broken Authentication	OIDC token and login endpoints can fail through broken authentication or trust handling.
Recommendation — Test authentication and token exchange paths for broken or spoofable authentication behavior.

Practitioner Guidance

Governance implication: Treat OIDC endpoint selection as part of application security ownership, not as a one-time integration detail. The issuer, discovery document, redirect handling, and token exchange path should be reviewed together because a mistake in any one of them can invalidate the whole trust chain.

What to watch for: Pay special attention when endpoint metadata is copied between environments, when a provider changes its signing or discovery configuration, or when a client is reused across multiple applications. Those are the moments when endpoint drift and trust confusion are most likely to create security exposure.

OIDC Endpoints