authentik is now OpenID Certified
authentik is an open source Identity Provider that unifies your identity needs into a single platform, replacing Okta, Keycloak, and Ping. Authentik Security is a public benefit company building on top of the open source authentik project.
As of version 2026.8, authentik is officially OpenID Certified™ by the OpenID Foundation. We're certified for the OpenID Provider profiles (Basic, Implicit, Hybrid, Config, and Form Post) and the logout profiles (RP-Initiated, Front-Channel, and Back-Channel).
Back in 2023, we wrote a post about why standards matter and mentioned that we were working on getting certified. This post is the follow-up to that one: how we got there, what the conformance tests found along the way, and why the certificate itself might be the least interesting part of all of this.
Why OIDC has a certification at all
OpenID Connect (OIDC) is the protocol that most modern applications use to log in through an identity provider like authentik. It's also one of the very few identity standards that comes with an official test program.
The OpenID Foundation publishes a conformance suite, which is a large set of tests that you run against your identity provider. These tests don't only check that you do the right thing when a request is correct, they also check that you fail in the correct way when a request is wrong. If you pass all the tests for a profile you can submit the results, and after a review your implementation gets listed as certified for that profile, on that specific version.
SAML has nothing like this officially. With SAML, "we support it" can mean pretty much anything, whereas with OIDC a certification tells you that someone outside of the company has had a look at it.
The OpenID Foundation was one of the very first things we joined when we started the company, because we've always thought this certification is valuable. That hasn't changed.
From passing tests to getting certified
The GitHub issue for the certification was created in February 2023. At that point we had already been using the conformance suite for a while to manually test our implementation, and shortly after there was a PR that made us pass the more basic test plans. We didn't submit anything right away though, and there were two reasons for that.
The first one was wanting to get the most out of a single certification. A certification is for a specific profile on a specific version, and we didn't want to get certified for one profile now and then for another one twelve months later, and keep doing that over and over. So whenever we added more things to our OAuth implementation, the plan turned into "okay, now we're adding this, so we'll certify after the next release." Single logout was one of those things, and so was most of the OAuth work in 2026.8.
The second one was simply priorities. Certification hadn't really come up with customers, and the features they were asking for were more pressing than a checkbox, even if it is a valid one to check off. OIDC in authentik worked that entire time, with applications logging in through it every day, we just didn't have the certification that said so.
In the end it was a couple of things coming together at the same time. Our single logout work in 2025.10 meant that we could pass the logout profiles as well, we had the conformance tests running automatically on every pull request, and we had a customer that was asking for it. At that point we had enough, everything was passing, so we decided to just do it.
What the tests found
Nothing too dramatic. Looking through the changes, none of it was too complicated or out of the ordinary. It was mostly a decent handful of slight incorrectness.
When we first ran the suite there was quite a bit of stuff that was very slightly broken. It was functional enough to work with pretty much every application out there, but there were a couple of fields that we weren't setting (or weren't setting quite correctly), and some behaviors required by the spec that we just didn't have, since no one had ever asked for them. We would have never found most of these without the suite, except through a lot of GitHub issues over a long time and a lot of manual testing.
The one that was annoying to implement was prompt=login. An application can add this parameter to an authorization request to tell the identity provider that the user has to authenticate again, even if they already have a session. In authentik this meant figuring out a good way to make the user re-authenticate, while also keeping all of the state of the original request around, so that after they've logged in again they still get sent back to the correct application with the correct parameters. That was clunky to figure out. It was also something we didn't really support before, but it's mandated by the conformance tests, so there was no way around it.
This is a side effect of certification that doesn't get mentioned a lot. Getting certified is quite likely to make you implement small sub-features and details that you haven't thought about, because none of your users have needed them yet. The upside is that afterwards there is a baseline. Instead of asking "does authentik support this specific parameter when used in this specific context," you can look at the certified profile, and everything that's in there is supported.
What the certificate is actually for
The obvious answer is that it's a kind of seal of quality. Think of it like a pen test done by an external company. It's not us saying "look, we tested this ourselves." It's an independent third party that has reviewed it and said yes, this is correct.
The less obvious answer has to do with debugging. Anyone that has integrated more than a handful of applications with an identity provider will have run into applications that aren't quite standards compliant, and those tend to break in weird ways. The first question is then always whose bug it is. Having run all of these tests, and having had the results reviewed, makes that question a lot easier to answer. We know that we implement the standard correctly, so it's more likely to be an issue on the other side. That's not about pointing fingers, it just helps a lot to have a starting point.
We also feel like this is kind of a given for an identity provider to have. Several self-hosted providers (us included) have been certified in the last year or so, and we expect that to become the norm.
Certified on which version?
There is one thing about the certification that we aren't too happy with, and that we don't have a good solution for either. It isn't specific to us; it applies to every certified implementation.
A certification is done on a given version, and there isn't really a way to do a smaller re-certification for the next release. So if you're running a version that is newer than the one on the list, the list by itself can't tell you whether that version is still compliant. A customer could quite reasonably say "you certified that version, but I'm running this one, which isn't certified, so what guarantee do I have?"
From the certificate itself, none. The only thing that does give you that guarantee is running the tests again, which is what we do on every pull request.
Running the conformance suite in CI
The OpenID Foundation publishes the conformance suite as a container image, and it has an API that allows you to control it from your own tests. In our CI pipeline, every pull request starts the conformance suite next to a test instance of authentik, and then runs seven jobs in parallel, one for each test plan:
- OIDC Basic
- OIDC Config
- OIDC Implicit
- RP-Initiated Logout
- Front-Channel Logout
- Back-Channel Logout
- Shared Signals Framework (SSF) transmitter
The tests themselves are in tests/openid_conformance. Each of them creates a provider in authentik, tells the suite to run a test plan against it, and then clicks through the browser parts using the same Selenium setup that we use for our end-to-end tests. After the run, the result files from the suite are uploaded as build artifacts, and those are the same files that you submit to the Foundation for a certification.
This was not our first attempt at automating this. A couple of years ago we tried to do the same thing using the automation that is built into the conformance suite, which is kind of like Selenium, but also very much not. It really struggled with our flow executor and we didn't get anywhere with it, so that attempt sat around for a while. What ended up working was only using the API of the suite and doing all of the browser automation ourselves.
Currently these jobs are not blocking, mostly because a full run can take quite a while, but they do run on every PR. In the time between the first passing run and the certification there were a couple of instances where we changed something that accidentally broke a small part of the spec, and we didn't notice for a while. This is exactly the issue with certifying a version once and then shipping features for three years afterwards, and it's the main reason these tests exist.
We're not the only ones doing this. The Keycloak OAuth SIG runs automated tests against the conformance suite as well. Looking through the list of certified implementations though, there are quite a few where it looks like the tests were run once, a long time ago, and not again since.
Testing against a spec that isn't finished
One of the seven test plans above can't be certified yet, which is the Shared Signals Framework (SSF). SSF allows an identity provider to send security events to other systems, for example that the session of a user has been revoked. The SSF spec itself was finalized in September 2025, but the conformance tests for it are still an alpha release. The Foundation says they may be incomplete or incorrect, and certification for SSF hasn't launched yet.
We ran them anyway, and there were a couple of cases where the spec said one thing and the test did another. For those we opened discussions with the maintainers of the conformance suite on their GitLab, asking which of the two is actually correct. That was a very pleasant experience and we figured all of it out, so we're already running against the SSF tests even though they're not certifiable yet.
We'd recommend doing this if you're implementing any of the newer sub-protocols. It makes it a lot more likely that your implementation is in line with what will eventually be released, and once SSF does become certifiable there shouldn't be much left for us to change.
Certified alongside good company
We weren't the only self-hosted identity provider that got certified this year. Pocket ID and Tinyauth were both listed within a couple of weeks of us, and Authelia got there a year earlier. This is great for everyone that self-hosts. Not too long ago most of the open source options weren't certified at all, and now most of the popular ones are.
What each project got certified for is quite different though, so it's worth having a look at what is behind the badge:
| Provider | Certified | OpenID Provider profiles | Logout profiles |
|---|---|---|---|
| authentik 2026.8 | July 2026 | Basic, Implicit, Hybrid, Config, Form Post | RP-Initiated, Front-Channel, Back-Channel |
| Authelia 4.39 | May 2025 | Basic, Implicit, Hybrid, Config, Form Post | None |
| Pocket ID v2.10 | July 2026 | Basic, Config, Form Post | None |
| Tinyauth v5.1 | June 2026 | Basic | None |
The Basic profile covers the authorization code flow, which is what most applications use, so it's the right place to start. Tinyauth and Pocket ID are also smaller projects with a very clear focus, and a smaller set of profiles makes sense for them. authentik on the other hand is meant to be the identity provider for everything in an organization, so we went for every profile that the suite offers for a general-purpose provider, and all three of the logout profiles on top of that. Of the self-hosted providers we usually get compared to, we're the only one with any of the logout profiles certified. Single logout is the part of OIDC that is most likely to be missing or slightly broken, which is why we're especially happy to have that one verified.
Ahead of the certification
The certification covers the core of OIDC. A bunch of the things that we shipped in 2026.8 are newer than that, and the conformance suite either can't fully test them yet or doesn't have any tests for them at all.
- Dynamic Client Registration (DCR) allows applications to register themselves with authentik, instead of an admin having to create each one by hand. This one is certifiable (there is a Dynamic OP profile for it), we just added it after we had already submitted our results. It's next on the list.
- Token exchange (RFC 8693) allows an application to exchange a token from a trusted provider for an authentik token for the same user. On-behalf-of (OBO) builds on top of that, so that a service (or an AI agent) can act for a user, with the resulting token containing both who the user is and who is acting for them. As far as we can tell there are no conformance tests for either of these. Having seen how the tests are written, we don't blame them; that's not easy.
- OpenID key binding issues ID tokens that are bound to a key held by the client, so a stolen token by itself is useless. There are no tests for this yet either. We do have a bit of an advantage here though, as one of the authors of the OpenID Connect Key Binding draft also implemented it for authentik.
- Shared Signals Framework (SSF) has tests, but as mentioned above they're still in alpha.
This is a part that the certificate doesn't show. For all of these newer features we basically had to be our own conformance suite: reading the specs very closely, writing our own tests, and comparing notes with the people writing the specs. That found bugs in our implementation that no certification would have caught, because there is no certification that covers them. We fixed them anyway.
This isn't the finish line
A certification is a snapshot. It says that one version of authentik passed a set of tests on a given day, which is good to have (and more than SAML can offer), but we don't want it to be seen as the end of something.
This is what's next for us:
- Certify the Dynamic OP profile, so that DCR is covered as well.
- Change our CI setup so that the conformance suite registers itself with authentik through DCR instead of using a pre-configured client. The suite already supports this, and it means DCR gets tested on every pull request.
- Certify SSF as soon as the tests for it are marked as finished. We already pass them.
- Add key binding and token exchange to the conformance runs once there are tests for them.
- Keep running the full suite on every pull request, so that the version you are running has gone through the same tests as the version that was certified.
If there's one thing to take away from this post it's that last point. Being on the list is nice, but the tests behind the list running every time we change the code is what makes it mean something.
If you have any questions about the certification or how we run the tests, you can find us on GitHub and Discord.