# OpenID-Connect-PHP: A Minimal OpenID Connect Client in Plain PHP

> OpenID-Connect-PHP is an Apache-2.0 licensed library that lets a PHP application authenticate a user through the basic OpenID Connect flow, with dynamic registration, PKCE, client credentials and back-channel logout in one class. It suits a developer who needs single sign-on without a large identity framework.

**jumbojett/OpenID-Connect-PHP** — Minimalist OpenID Connect client

- Repository: https://github.com/jumbojett/OpenID-Connect-PHP
- Website: https://github.com/jumbojett/OpenID-Connect-PHP
- Stars: 739 · Forks: 408
- Language: PHP
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jumbojett-openid-connect-php

## A basic flow, deliberately made small

OpenID-Connect-PHP is described as a simple library that allows an application to authenticate a user through the basic OpenID Connect flow, and its stated aim is to encourage OpenID Connect use by making it simple enough for a developer with little knowledge of the protocol to set up authentication. That framing is the design constraint. The whole client is one class, Jumbojett\OpenIDConnectClient, and the surface you touch is a constructor taking the provider URL, a client id and a client secret, then a short sequence of method calls. The acknowledgements in the readme name Justin Richer and Amanda Anganes for their help and support of the protocol, which tells you this was written by someone who read the specification closely rather than from a tutorial. The licence is Apache-2.0 and the requirement is PHP 7.2 or greater with the CURL and JSON extensions.

## Installing it and making a first authentication

Installation is one composer command.

```bash
composer require jumbojett/openid-connect-php
```

Then the autoloader goes at the top of your entry script.

```php
require __DIR__ . '/vendor/autoload.php';
```

The basic client is four lines of work.

```php
use Jumbojett\OpenIDConnectClient;

$oidc = new OpenIDConnectClient('https://id.provider.com',
                                'ClientIDHere',
                                'ClientSecretHere');
$oidc->setCertPath('/path/to/my.cert');
$oidc->authenticate();
$name = $oidc->requestUserInfo('given_name');
```

The readme links to the OpenID specification for the available user attributes, which tells you that requestUserInfo takes an attribute name and returns it, so the attribute vocabulary is the specification's rather than the library's. The setCertPath call is for providers that require a client certificate, and it is separate from the client secret in the constructor.

## Dynamic registration, when you cannot pre-register a client

The second example covers dynamic registration, which is the flow where the client registers itself with the provider instead of being pre-registered.

```php
use Jumbojett\OpenIDConnectClient;

$oidc = new OpenIDConnectClient("https://id.provider.com");

$oidc->register();
$client_id = $oidc->getClientID();
$client_secret = $oidc->getClientSecret();
```

Note that the constructor takes only the provider URL here, since the credentials do not exist yet. The comment in the example is the part worth carrying into your own code: be sure to add logic to store the client id and client secret. The library performs the registration and hands you the result, but persisting it is your responsibility, and a registration that is repeated on every request will create a new client on the provider each time.

## Client credentials, the resource owner flow and provider overrides

The machine-to-machine flow is a separate call, and it needs a token endpoint and a scope.

```php
$oidc->providerConfigParam(['token_endpoint'=>'https://id.provider.com/connect/token']);
$oidc->addScope(['my_scope']);

// this assumes success (to validate check if the access_token property is there and a valid JWT) :
$clientCredentialsToken = $oidc->requestClientCredentialsToken()->access_token;
```

The resource owner flow adds a username and password as auth params and returns a token the same way. The providerConfigParam call is how you tell the library where the token endpoint is when the provider's discovery document does not say, which is common with providers that publish a non-standard configuration. The comment about validation is the important caveat in both examples: the code assumes success, and to validate you check if the access_token property is there and a valid JWT. The library does not do the JWT verification for you in these paths.

## PKCE and the public client with no secret

The PKCE example is the one to look at if you are building a client that cannot keep a secret.

```php
use Jumbojett\OpenIDConnectClient;

$oidc = new OpenIDConnectClient('https://id.provider.com',
                                'ClientIDHere',
                                null);
$oidc->setCodeChallengeMethod('S256');
$oidc->authenticate();
$name = $oidc->requestUserInfo('given_name');
```

The client secret is null and the code challenge method is set to S256, which is the standard transformation rather than the plain variant. For a browser-based client this is the configuration that makes sense, because a secret shipped to the browser is not a secret. The implicit flow example, cited against the OpenID Connect core specification and mentioning Azure AD B2C, is the older alternative and it requires the response types, the allow-implicit flag and a form post response mode, plus a call to getVerifiedClaims for the subject.

## Token introspection and back-channel logout

Two operational flows round out the library. Introspection, following RFC 7662, asks the provider whether a token is still active.

```php
$data = $oidc->introspectToken('an.access-token.as.given');
if (!$data->active) {
    // the token is no longer usable
}
```

Back-channel logout is the more interesting one, and the readme explains the concept carefully. Back-channel authentication assumes you can end a session on the server side on behalf of the user without relying on their browser. The request is a POST from the provider direct to your relying party. The point of it is that your relying party can perform single sign out for the user even if they did not have your application open in a browser or on another device, but still had an active session there. Either the sid or the sub may be accessible from the logout token, and the library exposes getSidFromBackChannel and getSubjectFromBackChannel so you can match the token to a session and destroy it. The example that follows is explicitly hypothetical, since how you find and destroy a session is a matter for your own design.

## Client authentication methods that are off by default

The last documented example is about a default that catches people out. By default only client_secret_basic is enabled on the client side, which was the only method supported for a long time. Recently client_secret_jwt and private_key_jwt have been added, but they remain disabled until explicitly enabled.

```php
$oidc->setTokenEndpointAuthMethodsSupported(['client_secret_basic', 'client_secret_jwt']);
```

So a provider that expects a JWT-authenticated client will fail against a default configuration, and the fix is a one-line call naming the methods you want. That is a sensible design, since silently sending a client secret to a provider that does not want one is worse than requiring you to opt in. The method list is the set your provider advertises, so the value here is a configuration decision rather than a default to inherit.

## The repository, the release line and what the library is not

The repository is compact: a src/ directory with the library, a tests/ directory, a client_example.php at the root, a composer.json, a phpunit.xml.dist for the test runner, a CHANGELOG and a LICENSE. The release record shows v1.0.0 in December 2023, v1.0.1 in September 2024 and v1.0.2 a week later, and the last push was on 2026-08-17, so the library is maintained without being churned. What it is not is a framework. There is no session management, no user directory, no token storage policy and no key management for verification, so a project using it still has to decide how to store tokens and how to validate what comes back. The PHP version floor of 7.2 and the two extension requirements are also the reason it drops into an older codebase without a dependency fight, which is where this kind of library earns its place.

## Conclusion

OpenID-Connect-PHP fits a PHP application that needs plain OpenID Connect single sign-on and wants a small dependency with a readable API, and that is prepared to write its own session handling. It is the wrong choice if you want a full identity framework with discovery, key management and provider-specific quirks handled for you, because the library is deliberately minimal. It is also the wrong choice if you cannot keep a client secret, though the PKCE example shows the public client path. Before you deploy, check which token endpoint auth methods your provider expects and enable them explicitly, since only one is enabled by default.

## FAQ

### What does OpenID-Connect-PHP do?

It lets a PHP application authenticate a user through the basic OpenID Connect flow using a single client class, with methods for dynamic registration, PKCE, client credentials, resource owner tokens, token introspection and back-channel logout. It needs PHP 7.2 or greater with the CURL and JSON extensions.

### How do I install and use the library?

Run composer require jumbojett/openid-connect-php and require the vendor autoload.php. Then construct OpenIDConnectClient with the provider URL, client id and secret, optionally set a certificate path, call authenticate and fetch attributes with requestUserInfo.

### How do I use the library with a public client that has no secret?

Pass null as the client secret and call setCodeChallengeMethod with S256 before authenticate. That is the configuration for a client that cannot keep a secret, such as a browser-based one.

### Why does my provider reject the client authentication?

By default only client_secret_basic is enabled on the client side, even though client_secret_jwt and private_key_jwt have been added. Call setTokenEndpointAuthMethodsSupported with the methods your provider advertises to enable them.

### What does back-channel logout give me that a browser redirect does not?

It lets your relying party end a session server-side on the user's behalf without relying on their browser. The request is a POST from the provider direct to you, so single sign out works even when the user has no browser open to your application but still has an active session there.

## Sources

- [jumbojett/OpenID-Connect-PHP on GitHub](https://github.com/jumbojett/OpenID-Connect-PHP)
- [License: Apache-2.0](https://github.com/jumbojett/OpenID-Connect-PHP/blob/master/LICENSE)
- [Project website](https://github.com/jumbojett/OpenID-Connect-PHP)
- [README](https://github.com/jumbojett/OpenID-Connect-PHP/blob/master/README.md)
- [Releases](https://github.com/jumbojett/OpenID-Connect-PHP/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jumbojett-openid-connect-php