mod_auth_openidc 1 year anniversary

My project mod_auth_openidc, a module that implements OpenID Connect RP functionality for the Apache web server, is exactly 1 year old today so I thought it would be nice to describe the current status.

As always happens with these projects, it ended up to be a bit more than originally planned, in both features and work… Apart from the OpenID Connect RP functionality, it is now also a full-fledged OAuth 2.0 Resource Server that can validate an access token against an Authorization Server in a so-called “introspection call” or validate it locally if the access token is a JWT.

  • There are more than 75 configuration primitives and 4 types of supported caching/session-sharing backends (trust me, it is flexible, not overengineered…)
  • Over 200 unique visitors and 1000 views to the project website every week
  • over 50 people starred the Github project, over 20 forks in Github were created so far by other contributors, about 20 clones per week are pulled for local compilation/development
  • Almost 2000 downloads of binary packages (provided for Debian/Ubuntu/Redhat/CentOS)
  • included in the stock Ubuntu (Utopic) distribution and the upcoming stable release of Debian Jessie

Try it here:

This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to mod_auth_openidc 1 year anniversary

  1. SSG says:

    Hi Hans,

    I have a requirement in a project to have access to a legacy server be authenticated against PingFederate. I was considering “what if there was a proxy that would handle the OIDC portion of it” and lo-and-behold your wonderful Apache module shows up :). The more I read about the more I like it.

    There is a couple of areas that I am still hazy about (possibly because I am fairly new to the whole OpenID mindset). That is where I need a little help and any advice provided will be highly appreciated.

    As in any fairly modern server, there are 2 scenarios by which one can communicate with the server: (1) a user interface directly accessible from a browser suitable for “admin” type usage and (2) via an API suitable for apps. The apps in (2) reside on a domain and our server (and the OIDC proxy) sit in

    My plan is to have mod_auth_openidc process all requests to the protected server irrespective of the scenario. My first question is: does the OIDC proxy inject authentication/validation tokens as a cookie or as parameters in the request. Assuming the answer is “cookie”, my follow-up question is: which domain will be used to set the cookie, my concern is that if it is the domain of the proxy will the app (in scenario 2) have trouble accessing and reusing it for subsequent requests.

    As mentioned, any help will be appreciated.


  2. Alex says:

    Hi Hans,

    Thank you for the interesting topic. It motivated me to implement OpenId Connect in one of my projects. However, I am a bit struggling with the case when I would like to validate OpenId token on Resource Server side and try to do logout. My Authorization Server will know about user logout, but how should it notify Resource Server that token is not valid anymore? It could be a case when user after logout may go to Resource Server with his OpenId token.

    Best regards,

    • I think you’re mixing things here: the Apache server can be either an OpenID Connect RP or an OAuth 2.0 Resource Server, not both. In the OAuth 2.0 RS case: depending on how the token implementation (JWT vs. reference) the Resource Server may check with the Authorization Server if it is still valid. Perhaps worth taking up that discussion on the project’s mailing list.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s