Download the PHP package digitalcz/openid-connect without Composer

OIDC Connect

PHP implementation of OpenID Connect using symfony/contracts

Install

Via Composer

Usage

Initialization

Using the OIDC discovery endpoint

Configuration Options

The OidcFactory::create() method accepts the following configuration options:

Authentication Methods

• client_secret_post - Send client credentials in POST body
• client_secret_basic - Send client credentials in Authorization header
• client_secret_jwt - Use JWT signed with client secret
• private_key_jwt - Use JWT signed with private key
• none - No client authentication (public clients)

Authorization Code flow

Step 1 - Redirect the user to authorization endpoint

Step 2 - Handle the callback and exchange code for tokens

Client Credentials flow

Device Authorization flow

Implements the OAuth 2.0 Device Authorization Grant (RFC 8628) for browserless and input-constrained devices. Requires the provider to expose a device_authorization_endpoint.

Step 1 - Request a device and user code

Step 2 - Poll for tokens

pollForTokens() blocks until the user completes (or denies) authorization, honoring the server's polling interval and backing off automatically on slow_down:

If you need to drive the polling loop yourself, call fetchTokens() for a single attempt. It throws a typed exception per RFC 8628 error code: DeviceAuthorizationPendingException, SlowDownException, DeviceAuthorizationExpiredException, DeviceAuthorizationDeniedException, or the base DeviceAuthorizationException for any other error.

Resource Server (Token Validation)

To follow RFC 9068 and require JWT access tokens to be explicitly typed (rejecting, for example, an ID token presented as an access token), set accessTokenType:

When set, the typ header must be present and equal to the expected value; both at+jwt and application/at+jwt are accepted. It is disabled by default because not all authorization servers emit the typ header.

Audience validation

By default the resource server's JWT access-token validator accepts only tokens whose aud claim matches the clientId (opaque tokens are unaffected — they're validated via introspection, which only checks active). Use resourceServerAudience to decouple the accepted audience from the client id — for example when the resource server has several identities of its own, or when it must accept tokens minted for other first-party services:

Passing a list verifies that the token's aud (a single value or an array) intersects the configured audiences — this is the standard model for a resource server with multiple identities (RFC 9068 §4).

Passing null turns the audience check off. This is a deliberate deviation from RFC 9068, which requires rejecting a token whose aud does not identify the resource server. It exists for closed first-party token propagation across services sharing one issuer; the standards-correct alternative is Token Exchange (RFC 8693). The presence of the aud claim itself is still governed by the validator's mandatory-claims set. Leaving resourceServerAudience unset keeps the default (aud must equal clientId).

When wiring JwtAccessTokenValidator manually, the same string|list<string>|null values apply to its $audience argument. For fully custom validation you can inject a replacement set of claim checkers via $claimCheckers, which then supersedes the default issuer/audience/expiry/issued-at/not-before checkers.

Back-Channel Logout

Implements OpenID Connect Back-Channel Logout 1.0. The OP sends a server-to-server POST with a logout_token to your registered back-channel logout endpoint. Pass that token to the handler — it verifies the signature against the issuer JWKS and validates the logout-token claims (iss, aud, iat, events, no nonce, and sub and/or sid).

Two responsibilities the spec leaves to the application are intentionally left to you:

• Replay protection — verify the jti (exposed via $logoutToken->jti()) has not been seen recently before acting on the token.
• Session termination — map sid/sub to your session store and destroy the relevant session(s).

If the client is registered with backchannelLogoutSessionRequired: true, logout tokens without a sid claim are rejected.

See examples for more complete examples

Testing

Contributing

Please see CONTRIBUTING for details.

Security

If you discover any security related issues, please email [email protected] instead of using the issue tracker.

Credits

• Digital Solutions s.r.o.
• All Contributors

License

The MIT License (MIT). Please see License File for more information.