SAML-Toolkits/php-saml: a SAML service provider library for PHP with a security history worth reading
Simple SAML toolkit for PHP
At a glance
- What is it?
- php-saml is OneLogin's MIT licensed PHP library for building a SAML service provider, supporting single sign-on and single logout in both directions, assertion and nameId encryption, message signing and SP metadata. Its README is dominated by a security history, from the signature wrapping vulnerability that affects every version below 2.10.0 to the xmlseclibs upgrades of the last two years, and by a version matrix that spans PHP 7.0 to PHP 8.
- Who is it for?
- Adopt php-saml if you are building a PHP service provider that has to talk to an enterprise identity provider, because it implements the browser SSO profile, the logout flows and the signature handling that most of the difficulty in SAML lives in, and because its security history is documented in public rather than hidden.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 77 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the toolkit does
php-saml adds SAML support to PHP software, and the general description says it lets you build an SP, a Service Provider, over your PHP application and connect it to any IdP, an Identity Provider.
The feature list is the standard set of a browser single sign-on service provider. It supports SSO and SLO, single sign-on and single logout, in both directions, SP-Initiated and IdP-Initiated. It handles assertion and nameId encryption. It verifies assertion signatures, and it signs messages, specifically AuthNRequest, LogoutRequest and LogoutResponses. It lets you enable an Assertion Consumer Service endpoint and a Single Logout Service endpoint, and it can publish the SP metadata, which can itself be signed.
That last point is worth pausing on. Publishing unsigned SP metadata is a common shortcut and it lets anybody who reads the metadata file impersonate your service provider, so the ability to sign the metadata is not a nicety, it is the difference between a working integration and a forgeable one.
The key features list has a few entries that describe the shape of the design rather than the protocol coverage. `saml2int` implements the SAML 2.0 Web Browser SSO Profile, which is the profile almost every integration actually uses. The toolkit is session-less, and the phrasing is that you can forget the common conflicts between the SP and the final application because the toolkit delegates the session to the final app. There are two easy to use APIs, one high level and one low level. And it is tested, and popular, in the sense that many PHP SAML plugins use it underneath.
The project is the SAML PHP Toolkit maintained by OneLogin, MIT licensed and published on Packagist as `onelogin/php-saml`.
The version matrix comes before the install instructions
The README puts the version guidance at the very top, before the description, and that ordering is a warning.
The 3.X branch is compatible with PHP 7.0, 7.1 and 7.2, so if you are using that PHP version, use it and not the 2.X or the master branch. The 4.X branch is compatible with PHP 7.3 and above and with PHP 8.X.
So there are three live lines, and picking the wrong one is a mistake with security consequences, because the fixes in the README's history landed in the 2.x line and were then carried forward. The release list shows all three being maintained, with 3.8.2 published on 2026-05-11, 4.3.2 on 2026-05-07 and 2.21.2 on 2025-12-10, and the last push to the repository on 2026-08-07.
The 2.x line still being alive at all is a good sign about how the project handles long lived deployments. A SAML library is often the last thing an organisation upgrades, because it is a dependency of the identity provider integration and not a product feature, and a project that keeps a branch for old PHP is a project that understands that.
The security history is the most useful page in the repository
The warning section is a chronological list of the vulnerabilities and hardening changes, and for anyone integrating SAML it is the most valuable part of the README, because each entry is a class of attack you can now check for in your own deployment.
The most important line is the oldest and the bluntest. `php-saml < v2.10.0` is vulnerable and allows signature wrapping. Version 2.10.0 shipped a security patch with extra validations that prevent signature wrapping attacks, CVE-2016-1000253. The mechanism is worth understanding, because it is the reason the toolkit needs two levels of validation: an attacker can move a legitimate signature from one part of the XML document to another, so a validator that checks only that a signature is present and valid, rather than that it covers the specific element being consumed, will accept a forged assertion.
After that the list continues. Version 2.10.4 patched signature validation on LogoutRequests and LogoutResponses, which is the kind of gap that lets an attacker forge a logout. Version 2.15.0 carried a patch for XEE attacks, where XML entity expansion turns a small response into a memory exhaustion attack. Version 2.17.0 set strict mode active by default, which turns a set of permissive defaults off, and that is a default change worth reading about rather than a bug fix.
Version 2.17.1 updated xmlseclibs to 3.0.4 for CVE-2019-3465, with the note that php-saml was not directly affected since it implements additional checks that prevent exploiting that vulnerability, and version 2.21.1 updated xmlseclibs to 3.1.4 for CVE-2025-66475. That last pair is a reminder that this toolkit sits on top of a security-sensitive XML library, and that the maintainers track its advisories rather than assuming the dependency is fine.
Version 2.18.0 added two settings that are off by default and that a careful integrator should consider turning on. `rejectUnsolicitedResponsesWithInResponseTo` allows the toolkit to invalidate an unsolicited SAMLResponse, and it will reject a SAMLResponse if a requestId was provided to the validator but the response contains no InResponseTo attribute. And `destinationStrictlyMatches` forces that the Destination URL strictly matches the address that processed the response, which closes a class of confusion attack where a response captured at one endpoint is replayed at another.
Vulnerabilities in a security library are reported by mail to the maintainer, and the README gives the address.
Installing it, and the extensions you will need
There are three ways to install, and the composer route is the one most projects will use.
composer require onelogin/php-samlAfter installation you find a new `onelogin` folder in `vendor/`, with `php-saml` inside it, and you include it from there. The other two options are cloning the repository, with `git clone [email protected]:onelogin/php-saml.git`, which is the option to choose if you plan to work with the demos, since the release archive contains only the main files. The third is downloading a release or the master repository from GitHub and copying the core of the library into your application, with the reminder that each application has its own structure and you should take your time locating the right place for it.
The dependencies are listed separately, and two of them are conditional. You need PHP 5.3.3 or above with core extensions including php-xml, php-date and php-zlib, and the OpenSSL library, which handles the x509 certificates. You need `mcrypt` and its driver if you are going to handle encrypted data, meaning nameID and assertions, and you need `curl` and its driver if you plan to use the IdP metadata parser. The project notes that PHP 5.3 is officially unsupported and recommends a newer version.
The repository layout shows what is included beyond the library itself. There are `demo1/`, `demo2/` and a `demo-old/`, `certs/` for the certificates the demos need, `endpoints/` for the service provider endpoints, `extlib/` for the external libraries, `locale/` for translations, `docs/`, a `tests/` directory with a `phpunit.xml` for the test suite, and two example configuration files, `settings_example.php` and `advanced_settings_example.php`, alongside a `compatibility.php` and a `_toolkit_loader.php`.
Session-less, and what that obliges you to do
The session-less design is the decision that most affects how you integrate the toolkit, and it is described as letting you forget the common conflicts between the SP and the final application, because the toolkit delegates the session to the final app.
The reasoning is sound. In a SAML flow the identity provider authenticates the user and the service provider receives an assertion, and the question of how the SP represents that user in a session is a question about your application, not about the protocol. A library that created its own session would be making that decision for you, and it would be making it badly, because it does not know your session store, your cookie policy or your user model.
The consequence for the integrator is that you must carry the assertion's attributes into your own session yourself, and that you must decide what to do about a user whose assertion does not contain the attributes your application needs. Neither is hard, but both are yours, and skipping them is where most SAML integrations go wrong, because a half completed login that leaves a session behind is a security problem rather than a bug.
The other design point, the two APIs, is about how much of the protocol you want to see. The high level API handles the flow for you, and the low level one lets you work with the individual messages when an integration needs it, which is usually when something about the assertion is unusual.
Where php-saml is the wrong choice
The first wrong case is an unmaintained installation. If you are on a version below 2.10.0, the README says outright that the library is vulnerable to signature wrapping, and that is not a theoretical concern, it is a known bypass of the validation that the whole protocol depends on. The fix is an upgrade, and if you cannot upgrade the PHP version, the 2.x and 3.x lines exist precisely so that you do not have to.
The second is a service that has outgrown browser SSO. SAML is a redirect based protocol for a human with a browser, and an API to API integration, a mobile client or a service talking to a service is a different problem with different tools. A toolkit that implements the browser profile well is not a general identity library.
The third is a decision to own your own XML handling. The toolkit depends on xmlseclibs, and the security history shows the maintainers chasing that library's advisories. If your organisation has a policy against third party XML processing in an authentication path, the whole category is wrong rather than this package.
The fourth is an application that treats the identity provider as infallible. The toolkit validates the message it is given, and the settings that tighten validation, the strict destination match and the rejection of unsolicited responses, are off by default for compatibility reasons. Turning them on is a decision about your identity provider's behaviour, and it is a decision the README leaves to you.
On the state of the project, three branches are being maintained and released in parallel, the last push was on 2026-08-07, and the repository is not archived. The package is on Packagist with a dependency badge and download counts, the CI runs a PHP package workflow, and coverage is tracked through Coveralls with a `.coveralls.yml` in the tree, and the `CHANGELOG` file at the root is the place to look for what changed in a given release.
Editorial conclusion
Adopt php-saml if you are building a PHP service provider that has to talk to an enterprise identity provider, because it implements the browser SSO profile, the logout flows and the signature handling that most of the difficulty in SAML lives in, and because its security history is documented in public rather than hidden. Do not adopt it on an unpatched version, since the README states plainly that anything below 2.10.0 is vulnerable to signature wrapping, and do not let the library manage your session, because the toolkit is session-less by design and that is your responsibility. Verify first which branch matches your PHP version, that you are past the signature wrapping fixes, that mcrypt and curl are installed if you handle encrypted assertions or parse IdP metadata, and that your metadata is signed rather than published unsigned.
Frequently asked questions
What does the php-saml library do?
It lets you build a SAML service provider over a PHP application and connect it to any identity provider. It supports single sign-on and single logout in both SP-Initiated and IdP-Initiated directions, assertion and nameId encryption, assertion signatures, message signatures for AuthNRequest, LogoutRequest and LogoutResponses, an Assertion Consumer Service endpoint, a Single Logout Service endpoint, and publishing SP metadata that can be signed.
Which php-saml branch should I use?
The 3.X branch is compatible with PHP 7.0, 7.1 and 7.2 and the README says to use it rather than the 2.X or master branch on those versions. The 4.X branch is compatible with PHP 7.3 and above including PHP 8.X. The 2.X line is still released, with 2.21.2 published on 2025-12-10.
Is php-saml affected by signature wrapping attacks?
Only below version 2.10.0, which the README states plainly is vulnerable and allows signature wrapping. Version 2.10.0 shipped extra validations preventing signature wrapping attacks, CVE-2016-1000253, and 2.10.4 separately patched signature validation on LogoutRequests and LogoutResponses.
What PHP extensions does php-saml need?
PHP 5.3.3 or above with core extensions such as php-xml, php-date and php-zlib, plus the OpenSSL library for x509 certificates. You also need `mcrypt` and its driver if you handle encrypted data such as nameID and assertions, and `curl` and its driver if you use the IdP metadata parser.
How do I install php-saml with composer?
Run `composer require onelogin/php-saml`. After installation a new `onelogin` folder appears in `vendor/` with `php-saml` inside it, and you include it from there. You can also clone the repository, which is the option to use if you want the demos, since the release archive contains only the main files.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/saml-toolkits-php-saml)Was this useful?