A WebAuthn Apache module?

It is a question that people (users, customers) ask me from time to time: will you develop an Apache module that implements WebAuthn or FIDO2. Well, the answer is: “no”, and the rationale for that can be found below.

At first glance it seems very useful to have an Apache server that authenticates users using a state-of-the-art authentication protocol that is implemented in modern browsers and platforms. Even more so, that Apache server could function as a reverse proxy in front of any type of resources you want to protect. This will allow for those resources to be agnostic to the type of authentication and its implementation, a pattern that I’ve been promoting for the last decade or so.

But in reality the functionality that you are looking for already exists…

The point is that deploying WebAuthn means that you’ll not just be authenticating users, you’ll also have to take care of signing up new users and managing credentials for those users. To that end, you’ll need to facilitate an onboarding process and manage a user database. That type of functionality is best implemented in a server-type piece of software (let’s call it “WebAuthn Provider”) written in a high-level programming language, rather than embedding it in a C-based Apache module. So in reality it means that any sensible WebAuthn/FIDO2 Apache module would rely on an externally running “Provider” software component to offload the heavy-lifting of onboarding and managing users and credentials. Moreover, just imagine the security sensitivity of such a software component.

Well, all of the functionality described above is exactly something that your average existing Single Sign On Identity Provider software was designed to do from the very start! And even more so, those Identity Providers typically already support WebAuthn and FIDO2 for (“local”) user authentication and OpenID Connect for relaying the authentication information to (“external”) Relying Parties.

And yes, one of those Relying Parties could be mod_auth_openidc, the Apache module that enables users to authenticate to an Apache webserver using OpenID Connect.

So there you go: rather than implementing WebAuthn or FIDO2 (and user/credential management…) in a single Apache module, or write a dedicated WebAuthn/FIDO2 Provider alongside of it and communicate with that using a proprietary protocol, the more sensible choice is to use the already existing OpenID Connect protocol. The Apache OpenID Connect module (mod_auth_openidc) will send users off to the OpenID Connect Provider for authentication. The Provider can use WebAuthn or FIDO2, as a single factor, or as a 2nd factor combined with traditional methods such as passwords or stronger methods such as PKI, to authenticate users and relay the information about the authenticated user back to the Apache server.

To summarise: using WebAuthn or FIDO2 to authenticate users to an Apache server/reverse-proxy is possible today by using mod_auth_openidc’s OpenID Connect implementation. This module can send user off for authentication towards a WebAuthn/FIDO2 enabled Provider, such as Keycloak, Okta, Ping, ForgeRock etc. This setup allows for a very flexible approach that leverages existing standards and implementations to their maximum potential: OpenID Connect for (federated) Single Sign On, WebAuthn and FIDO2 for (centralized) user authentication.

Posted in Uncategorized | Leave a comment

OpenID Connect for Oracle HTTP Server

Over the past years ZmartZone enabled a number of customers to migrate their Single Sign On (SSO) implementation from proprietary Oracle HTTP Server components to standards-based OpenID Connect SSO. Some observations about that:

  • Oracle Webgate and mod_osso are SSO plugins (aka. agents) for the Oracle HTTP Server (OHS) that implement a proprietary (Oracle) SSO/authentication protocol that provides authentication (only) against Oracle Access Manager
  • the said components are closed source implementations owned by Oracle
  • these components leverage a single domain-wide SSO cookie which has known security drawbacks, especially in todays distributed and delegated (cloud and hybrid) application landscape, see here
  • ZmartZone supports builds of mod_auth_openidc that can be used as plugins in to Oracle HTTP Server (11 and 12), thus implementing standards based OpenID Connect for OHS with an open source component
  • those builds are a drop in replacement into OHS that can even be used to set the same headers as mod_osso/Webgate does/did
  • mod_auth_openidc can be used to authenticate to Oracle Access Manager but also to (both commercial and free) alternative Identity Providers such as PingFederate, Okta, Keycloak etc.
  • when required Oracle HTTP Server can be replaced with stock Apache HTTPd
  • the Oracle HTTP Server builds of mod_auth_openidc come as part of a light-weight commercial support agreement on top of the open source community support channel

In summary: modern OpenID Connect-based SSO for Oracle HTTP Server can be implemented with open source mod_auth_openidc following a fast, easy and lightweight migration plan.

See also:

Posted in Uncategorized | Leave a comment

mod_auth_openidc vs. legacy Web Access Management

A sneak preview of an upcoming presentation about a comparison between mod_auth_openidc and legacy Web Access Management.

Posted in Uncategorized | 1 Comment

Using an OAuth 2.0 Resource Server with Certificate-Bound Access Tokens

ZmartZone has implemented OAuth 2.0 Resource Server functionality in Apache/NGINX modules so these components can be used as a reverse proxy in front of APIs or other backends. In such a setup the backend does not have to deal with security but outsources it to a proxy sitting in front of it in a similar way that TLS termination is often offloaded to a load-balancer.

Most of the OAuth 2.0 deployments today use so-called bearer access tokens that are easy to deploy and use. This type of access token is not bound to the Client presenting the token which means that an attacker intercepting an access token can just use that token to get access to the resources/APIs/services as if it were the Client. So called Proof-of-Possession semantics for access tokens prevent that type of attack and present a more secure setup but such a system is typically harder to implement, deploy and maintain.

A relative simple variant of Proof-of-Possession for access tokens is specified in RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens. This specification leverages a (possibly self-signed) certificate held by the Client to bind an access token cryptographically to the private key associated with that certificate.

This specification is implemented in liboauth2 1.4.1 which is used in the Apache module mod_oauth2 3.2.1. This means that you can now require and verify OAuth 2.0 certificate bound access tokens for your API in a very simple way that is easy to deploy. All it takes is an Apache server in front of your API, configured with something like:

AuthType oauth2
OAuth2TokenVerify jwk "{\"kty\":\"RSA\",\"kid\":\"one\",\"use\":\"sig\",\"n\":\"...\",\"e\":\"AQAB\" }" type=mtls&mtls.policy=optional
SSLVerifyClient optional_no_ca

Acknowledgement: this work was performed in a partnership with Connect2ID. Thanks Vladimir Dzhuvinov.

Posted in Uncategorized | Leave a comment

MVP OAuth 2.x / OpenID Connect modules for NGINX and Apache

Last year I wrote about a new development of a generic C-library for OAuth 2.x / OpenID Connect https://hanszandbelt.wordpress.com/2019/03/22/oauth-2-0-and-openid-connect-libraries-for-c/.

It’s taken a bit longer than anticipated – due to various circumstances – but there’s now a collection of modules that is at the Minimum Viable Product stage i.e. the code is stable and production quality, but it is limited in its feature set.


Posted in Uncategorized | 1 Comment

Replacing legacy enterprise SSO systems with modern standards

I would like to highlight a digital transformation that I have witnessed and contributed to since a few years now. This transformation is about the adoption of standards based software to achieve Single Sign On (SSO) in enterprise environments, replacing legacy vendor systems that have been around for a decades.

About 20 years ago companies started to implement intra-enterprise SSO based on vendor proprietary mechanisms and protocols. This comes with a strong dependency on the vendor  and over the years thereafter in most cases it resulted in extremely high costs in licensing, infrastructure and professional services.

In addition, the legacy mechanisms are often based on enterprise-wide cookies which makes them vulnerable to user impersonation attacks, especially from insiders, and also makes it hard to move applications into the cloud. See also: https://hanszandbelt.wordpress.com/2015/12/14/the-importance-of-audience-in-web-sso/

On top of that, many legacy systems would come with proprietary “agent” software that has strong a dependency on (a specific version of) the policy server from the same vendor, making upgrades very painful and time consuming. Implementing an open standard reduces that dependency and makes it easier to apply upgrades or switch between vendors.

I have observed that the biggest uptake of the OpenID Connect standard recently is in enterprise SSO, replacing legacy vendor proprietary systems and I am happy be able to contribute to that in the form of open source software for a variety of web servers and reverse proxies. Please reach out to me if you think this software can be useful for your business as well.

Posted in Uncategorized | 1 Comment

Deploy OpenID Connect and OAuth 2.0 with a Reverse Proxy Architecture

I haven’t had much time for blog posts lately but if you are interested in my take on modern identity and how to rollout OpenID Connect and OAuth 2.0 for all of your applications without modifying them, please see the recording of my talk last June 26 at Identiverse 2019 in Washington DC titled “Deploy OpenID Connect and OAuth 2.0 with a Reverse Proxy Architecture”.

Posted in Uncategorized | 1 Comment

OAuth 2.0 and OpenID Connect libraries for C

Just about 5 years ago I started to develop an OpenID Connect plugin for the Apache web server.  Over the years it has become a pretty popular project and lots and lots of input from real world experience has come along to improve it. As with all software, there comes a time to revisit the initial idea, the design choices and the scope of the project and that is exactly what I have done over the last 6 months.

I found that a lot of existing code could be refactored into a generic OAuth/OIDC library for C and that that library could then conveniently be used to build C-based plugins for various web servers and reverse proxies, not just Apache. This is similar to the approach that mod_security version 3 took. Today marks the announcement of such libraries for OAuth 2.0 / OpenID Connect and the availability some of these plugins. Here’s what I came up with so far:

And here is the first batch of plugins built on those libraries:

Note that over the course of 2019 I will rewrite mod_auth_openidc into version 3 that leverages liboauth2 and at the same time develop a native plugin (called ngx_openidc_module) for NGINX.

Please reach out to me if you want to be an early adopter of the new stuff and are willing to provide feedback.

Posted in Uncategorized | Leave a comment

Token Binding specs are RFC: deploy NOW with mod_token_binding

Update 10/18/2018: Google Chrome actually removed Token Binding support in version 70 so you’ll have to be on an older version to see this work in action, or use MS Edge, also see here. See here to learn how to run two Chrome versions side-by-side.

Today the so-called Token Binding specifications have formally been promoted to proposed standards RFC by the IETF. Essentially those specs define how to securely bind tokens to the communication channel running between a client and a server. As simple as that sounds, it is an extremely important step forward in web security: tokens are used everywhere across the Internet today  (e.g. for SSO, APIs, Mobile Apps) but moreover, the ubiquitous HTTP cookie also falls into the security token category.

In this post we’ll focus on securing HTTP cookies in Web Applications. HTTP cookies are pervasive on the web yet the vulnerability window for stealing such a cookie is usually larger than the window for stealing a security token, the damage is typically larger and abuse is harder to detect. Applying Token Binding to HTTP cookies closes a vulnerability in the web application landscape and prevents session hijacking by stealing a session cookie. See for example a class of XSS attacks that will now fail: https://www.hackeroyale.com/cookie-stealing-xss/ but also retrieving a session cookie from application/server logs, from the network, or through malicious client software etc. is no longer effective.

Implementing the Token Binding protocol itself in your application by interfacing with the TLS layer is complex and may go wrong easily. So how can an application leverage Token Binding today without jumping through time-consuming and dangerous hoops . Well, applications on or behind Apache are catered for by mod_token_binding: they can leverage a header or environment value set by mod_token_binding in their session cookie (or in other tokens they generate for that matter). The hard protocol security bits are dealt with by mod_token_binding and a trivial 2-step implementation process remains for the application itself. See below for a sample in PHP:

  1. At session creation time: put the Token Binding ID provided in the environment variable set by mod_token_binding into the session state
$tokenBindingID = apache_getenv('Sec-Provided-Token-Binding-ID');
if (isset($tokenBindingID)) {
  $_SESSION['TokenBindingID'] = $tokenBindingID;

2. On subsequent requests: check the Token Binding ID stored in the session or token against the (current) Token Binding ID provided in an environment variable

if (array_key_exists('TokenBindingID', $_SESSION)) {
  $tokenBindingID = apache_getenv('Sec-Provided-Token-Binding-ID');
  if ($_SESSION['TokenBindingID'] != tokenBindingID) {

Et voila, we’ve bound the PHP session cookie to the TLS channel with the Token ID provided by mod_token_binding that’s all there is to it!

As another example is mod_auth_openidc, the OpenID Connect RP client for Apache HTTPd. This module already leverages this functionality for its own session cookie, its state cookie and the id_token, the latter if only supported by the Provider.

Anyone using mod_auth_openidc should look to deploy it in conjunction with the Token Binding module now! (but be aware that you need to upgrade your Apache server to >= 2.4.26 and build/deploy it with a OpenSSL >= 1.1.1 stack)

But also legacy applications may use Apache HTTPd with mod_auth_openidc deployed as a Reverse Proxy in front of their origin server so that their own session can only be started/accessed through an authenticated OIDC session cookie that leverages Token Binding. That makes them now effectively use Token Binding to protect themselves against session hijacking without touching the application and/or their own application session cookie [1].

Looking forward to lots of happy mod_token_binding usage!

[1] Note that the users’s browser also needs to support Token Binding to leverage all of this good work, but Microsoft’s Edge and Google’s Chrome already do this and support in other browsers such as Firefox is near.

Posted in Uncategorized | Leave a comment

A Security Token Service client for the Apache webserver

I’ve recently been working on mod_sts a so-called Security Token Service client for the Apache web server. This module allows for exchanging arbitrary security tokens by calling into a remote Security Token Service (STS). It operates as a so-called “active” STS client, i.e. a non-browser, non-interactive STS client. The STS function allows for creating a split between tokens presented from remote security domains (customers, clients, partners, consumers) and tokens generated and used within an internal (or in any case, a different) security domain. So why would you want to do that:

  • a split between external (“source”) tokens and internal (“target”) tokens may be enforced for security reasons, to separate external requests/tokens from internal requests/tokens whilst keeping “on-behalf-of-a-user” semantics; backend services would never see/obtain customer tokens directly, which may satisfy a compliance/regulatory obligation or just good security practice because internal services woud not be able to impersonate the original client
  • for legacy reasons in case your backend only supports consuming a proprietary/legacy token format/protocol and you don’t want to enforce support for that legacy onto your external clients that use a standardized token/protocol (or vice versa…)
  • when the backend service needs to call a 3rd-party service to fulfill its function it is good security practice to obtain a new token “on its own behalf” rather than calling the remote service with the source token obtained from its client; this use case is often handled with a static service credential but in that case the (verifiable) context of the original user is lost; the STS allows for obtaining a new token for calling a 3rd-party service whilst retaining the “on-behalf-of” semantics for the original client/user

This module can be used in scenario’s where an Apache server is put in front of an origin server as a Reverse Proxy/Gateway that consumes “source” tokens presented by external clients but needs to forward those requests presenting a different “target” security token, turning around and acting as its own client to a backend service. Note that the backend service can also be an application that is hosted on the Apache server itself, e.g. a PHP application or a 3rd-party provided application.

I turned out as a pretty generic and powerful module catering for “delegation”, “impersonation” and “legacy wrapping” scenario’s as described above, dealing with:

  1. arbitrary incoming token formats and protocols e.g. OAuth 2.0 access tokens, cookies, JWTs, legacy tokens in headers etc.
  2. arbitrary outgoing token formats and protocols e.g. OAuth 2.0 access tokens,  vendor specific or legacy cookies/tokens, JWTs etc.
  3. a few types of – somewhat standardized – STS protocols i.e. WS-Trust, but also the new OAuth 2.0 Token Exchange protocol, a work in progress and even a “twisted” Resource Owner Password Credentials grant that I’ve seen a number of times in the field being used for that purpose

You’ll be pleased to know that it plays nicely with mod_auth_openidc in OAuth 2.0 Resource Server mode, consuming a verified access token from an environment variable set by mod_auth_openidc.

Happy STS-ing with mod_sts and let me know if you have questions, suggestions or need support.

Posted in Uncategorized | 1 Comment