HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
OpenIDC
mod_auth_openidc
C2014–2026
OpenIDC / mod_auth_openidc

mod_auth_openidc

OpenID Certified™ OpenID Connect and FAPI 2 Relying Party module for Apache HTTPd

6Distinct people
16Mentions
0Explicit recommenders
1.1KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

OpenID Certified™ OpenID Connect and FAPI 2 Relying Party module for Apache HTTPd

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 3:30:57 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year16 dated mentions

Observed mentions: 2014-04-24 16:44:07 UTC to 2026-02-21 08:10:49 UTC.

02462014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC505
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC615
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

6 sources
> that's irrelevant to the core developers That's relevant to me! If I want Apache to act as an OpenID connect relying party, for example, I can just use mod_auth_openidc https://github.com/OpenIDC/mod_auth_openidc installing which is pretty much trivial and requires little work on my part: sudo apt install libapache2-mod-auth-openidc If I want something similar for Nginx, I can take a look here https://openid.net/developers/certified-openid-connect-imple... and realize that I'll need to use OpenResty with LuaRocks, which does add a bit more complexity: https://github.com/zmartzone/lua-resty-openidc luarocks install lua-resty-openidc If I want a basic WAF with something that runs ModSecurity rules, on Apache I can just do: libapache2-mod-security2 and can use the OWASP CRS with no issues: https://owasp.org/www-project-modsecurit
Read the rest
y-core-rule-set/ With Nginx that is no longer properly supported and needed their Plus version anyways: https://docs.nginx.com/nginx-waf/admin-guide/nginx-plus-mods... sudo apt-get install nginx-plus-module-modsecurity If I want to do that myself with the regular Nginx, I suddenly have to compile a bunch of stuff myself, which becomes far less pleasant and a bit more long winded: https://www.linode.com/docs/guides/securing-nginx-with-modse... sudo apt-get install bison build-essential ca-certificates curl dh-autoreconf doxygen \ flex gawk git iputils-ping libcurl4-gnutls-dev libexpat1-dev libgeoip-dev liblmdb-dev \ libpcre3-dev libpcre++-dev libssl-dev libtool libxml2 libxml2-dev libyajl-dev locales \ lua5.3-dev pkg-config wget zlib1g-dev zlibc libxslt libgd-dev sudo apt install git cd /opt && sudo git clone https://github.com/SpiderLabs/ModSecurity cd ModSecurity sudo git submodule init sudo git submodule update sudo ./build.sh sudo ./configure sudo make sudo make install cd /opt && sudo git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git cd /opt && sudo wget http://nginx.org/download/nginx-1.14.0.tar.gz sudo tar -xvzmf nginx-1.14.0.tar.gz cd nginx-1.14.0 sudo ./configure --add-dynamic-module=../ModSecurity-nginx <Configure Arguments> sudo make modules sudo mkdir /etc/nginx/modules sudo cp objs/ngx_http_modsecurity_module.so /etc/nginx/modules (old versions in the example, but same principle) At that point I might as well look in the direction of OWASP Coraza: https://coraza.io/ When it comes to ACME and Let's Encrypt, I can use mod_md out of the box with Apache: https://httpd.apache.org/docs/2.4/mod/mod_md.html It's experimental but works nicely in my experience, whereas with Nginx, I have to go with Certbot separately: https://certbot.eff.org/ If I want everything in a single package, I can just use Caddy instead (which is a lovely web server). And that's before I get into weird Nginx behavior when I try to use it with containers, where the whole web server crashes, just because it cannot find the DNS record for a container that hasn't been created yet, along the lines of: nginx: [emerg] host not found in upstream "my-app" where trying to use the suggested fix leads to: nginx: [emerg] "proxy_redirect default" cannot be used with "proxy_pass" directive with variables and using other values often breaks app redirects. Due to these experiences, I'll absolutely say that you can do more with Apache, in ways that will be less of a pain, except for the whole "getting your entire web server hacked" or "brought down by any sizeable amount of traffic" bit. Nginx is really good for hosting static content or acting as a basic reverse proxy, but will be harder to get various bits of the greater ecosystem into it, as opposed to how Apache works. Then again, I fully acknowledge that someone will come along and say "ModSecurity isn't very useful, you should just put your site behind Cloudflare if you need a WAF." or maybe even "Don't handle OpenID Connect in your ingress, even if that means that in the case of 5 APIs you'll need OIDC libraries and configuration for each of them, which will look quite different in various languages." but that doesn't change the fact that some things are just more doable in one option instead of another. OpenResty or Caddy increasingly feel like better choices for a lot of stuff, but not bare Nginx. Use Nginx when you want to handle simple use cases (reverse proxy, serving static files) with good performance, security and a sane configuration format.
In Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server
> I think today it would not be unreasonable to take a "microservice" kind of approach where auth is handled by some self-contained system through an API but practically you might want to be able to join stuff against your user table. One option for writing less code yourself might be using something like Auth0 (cloud) or Keycloak (self-hosted) with some OpenID Connect library for your tech stack, or a Relying Party implementation altogether, like: https://github.com/OpenIDC/mod_auth_openidc They'll get you most of the way there, without making you write a bunch of security related code yourself (which is also more likely to cause issues, if someone isn't familiar with the domain).
In Ask HN: How to build site with payment, subscriptions, user login, registration
That's fair! Honestly, it's kind of cool to see how many different kinds of packages are available for Apache. A bit off topic, but I rather enjoyed the idea behind mod_auth_openidc, which ships an OpenID Connect Relying Party implementation, so some of the auth can be offloaded to Apache in combination with something like Keycloak and things in the protected services can be kept a bit simpler (e.g. just reading the headers provided by the module): https://github.com/OpenIDC/mod_auth_openidc Now, whether that's a good idea, that's debatable, but there are also plenty of other implementations of Relying Party out there as well: https://openid.net/developers/certified-openid-connect-imple... I am also on the fence about using mod_security with Apache, because I know for a fact that Cloudflare would be a better option for that, but at the sa
Read the rest
me time self-hosting is nice and I don't have anything too precious on those servers that a sub-optimal WAF would cause me that many headaches. I guess it's cool that I can, even down to decent rulesets: https://owasp.org/www-project-modsecurity-core-rule-set/ though the OWASP Coraza project also seems nice: https://coraza.io/
In Never Update Anything
In my eyes, that felt like something that should be separate from any given app or back end API, so in my case I use mod_auth_openidc: https://github.com/OpenIDC/mod_auth_openidc with Keycloak: https://www.keycloak.org/ My back end/app just gets a few headers that say who an authenticated user is, if they are logged in. When I need to log in or create a user, I can just direct them to the Keycloak SSO portal, where they can also use social login. It's using OpenID Connect without the insanity of dealing with the low level logic. And the Relying Party implementations work across any technology, be it PHP or Ruby, Node, Python or anything else (a simple auth filter that checks the headers is trivial across all of them).
In Why I love Laravel (2022)
I did something similar, though picked Apache with mod_auth_openidc, which is a certified Relying Party implementation: https://github.com/OpenIDC/mod_auth_openidc In other words, I can protect arbitrary applications through my reverse proxy and require either certain claims/roles, or simplify auth to the point where my downstream app/API will just receive a bunch of headers like OIDC_CLAIM_sub, OIDC_CLAIM_name, OIDC_CLAIM_email through the internal network, not making me bother with configuring OIDC libraries for all of my APIs and configure them in each stack that I might use, but rather contain all of that complexity in the reverse proxy. Handling headers in pretty much every stack is trivial, be it something with .NET, Java, Node, Python and so on... Basically: user <==> Apache (with mod_auth_openidc) <==> API (with OIDC_ headers, i
Read the rest
f logged in and authorized) OR <==> Keycloak (for logging in/registration, followed by redirect) Apache probably isn't the ideal tool for this, but was definitely the easiest to setup and also has mod_md nowadays, making renewing SSL certs (with HTTP-01, at least) closer to how Caddy might do it, I don't even need certbot: https://httpd.apache.org/docs/trunk/mod/mod_md.html Now, right now I'm moving away from storing groups in the Keycloak DB because it's actually easier to do that in the app DB and only allow Keycloak to reason about who users are, not what they can do (since interacting with Keycloak's API to manage users is cumbersome), especially when I want custom permissions: like users being assigned to companies, but also having specific permissions for each of those companies, your typical granular system. Personally, I'd definitely say that OIDC feels overcomplicated to work with, so I'm glad that I discovered something like this. There's a whole list of other Relying Party implementations, but nobody really seems to be talking about them: https://openid.net/developers/certified-openid-connect-imple... Also, in regards to Keycloak in particular, most likely you really want to build the "optimized" image, because otherwise the startup times will be annoyingly long: https://www.keycloak.org/server/containers (like the article already points out, but that was a pain point until I got it over with) Oh, and Keycloak is known to be a bit odd in how it sometimes works behind a reverse proxy, I actually needed to put this in the configuration because otherwise connections would sometimes break: SetEnv proxy-initial-not-pooled 1 SetEnv proxy-nokeepalive 1
In Keycloak SSO with Docker Compose and Nginx

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.