One of the most discussed concepts about authentication today is the concept of Single Sign-On, or SSO. SSO is the ability for a user to log into one location, and authenticate across several domains without entering any additional credentials. This saves the user from having to enter several credentials for related websites, as well as possibly prevent the user from having to remember multiple logins.
While developing the Rolling Stone and Vogue Archives, we needed a SSO system that could integrate our ASP.Net based archive with each provider’s existing authentication systems, primarily Apache-based web applications. Our solution was to develop a C# implementation of mod_auth_tkt cookie-and-token based authentication system, which we have since released open source.
Creating a C# implementation of mod_auth_tkt allowed us to use an IIS-hosted ASP.Net website as a mod_auth_tkt SSO endpoint, eliminating the need to handle login on our application side. Instead, we could redirect all logins to a single login page on the provider’s website, removing the security burden of having multiple login endpoints.
Mod_auth_tkt’s custom userData also allows us to read a subscription level from the cookie itself, and treat the user accordingly. Without the need to access Vogue’s internal database, we are able to securely transfer this information through the client side by validating the mod_auth_tkt hash.
History of Mod_Auth_Tkt
Mod_auth_tkt was originally written and released by Raimondas Kiveris, a software engineer working for GlobalWorks. Soon after the project was released under the Apache license, Gavin Carr of Open Fusion took over administration of the project and released mod_auth_tkt version 2.0 in February of 2005.
The original version of mod_auth_tkt, version 1.3, was written specifically for the Apache web server as a secure way to track an authenticated user, especially across web farms. It provided a secure way of keeping track of an authenticated user for Apache, by using an md5 hash to validate the user’s authentication cookie. The hash would validate both a userId, as well as a single text data field, although the cookie was also able to store other token data.
Version 2.0 was created to address a vulnerability with the 1.3 version of mod_auth_tkt. In version 1.3, any tokens set in the mod_auth_tkt cookie were not included in the hash, allowing unscrupulous users to change the data. In version 2.0, all tokens are also hashed, preventing users from changing the token data.
Mod_auth_tkt provides a cookie-based single sign-on that is compatible with any language that has an implementation built.
Mod_auth_tkt works by using a hash, usually MD5, of the user’s information salted with a secret key, IP address, and timestamp. The salt, user’s id, tokens, and userdata will be concatenated together, and then hashed to create a digest which is prepended to the plain text cookie data. When a remote server receives the cookie, the server only needs to hash the plain text data, and verify that the computed digest is equal to the digest in the cookie. This ensures the user is unable to modify the cookie without invalidating the cookie’s digest.
Nonetheless, like most technologies, mod_auth_tkt also has its own set of hurdles. In HTML, cookies are domain-specific, which presents a challenge when authenticating a user on a separate domain. To get around this, the token can be passed across domains using a HTTP POST call when redirecting from one server to another. Additionally, since mod_auth_tkt is primarily a cookie-based authentication, many implementations of mod_auth_tkt will not work on systems where cookies are disabled.
Mod_auth_tkt was a useful tool for implementing SSO with the Rolling Stone and Vogue Archives. Authentication using mod_auth_tkt lets us securely authenticate while keeping the login on the provider side, and keeps the user from having to log in twice.
For more information about mod_auth_tkt, take a look at our sample C# implementation on GitHub.