Authlogic is a clean, simple, and unobtrusive ruby authentication solution.

What inspired me to create Authlogic was the messiness of the current authentication solutions. Put simply, they just didn't feel right, because the logic was not organized properly. As you may know, a common misconception with the MVC design pattern is that the model “M” is only for data access logic, which is wrong. A model is a place for domain logic. This is why the RESTful design pattern and the current authentication solutions don't play nice. Authlogic solves this by placing the session maintenance logic into its own domain (aka “model”). Moving session maintenance into its own domain has its benefits:

  1. It's easier to update and stay current with the latest security practices. Since authlogic sits in between you and your session it can assist in keeping your security up to date. For example: upgrading your hashing algorithm, helping you transition to a new algorithm, etc. Since all of this logic is in the Authlogic library, staying up to date is as easy as updating the library.

  2. It ties everything together on the domain level. Take a new user registration for example, no reason to manually log the user in, authlogic handles this for you via callbacks. The same applies to a user changing their password. Authlogic handles maintaining the session for you.

  3. Your application can stay clean, focused, and free of redundant authentication code from app to app. Meaning generators are NOT necessary. Not any more neccessary than any other control

  4. A byproduct of #3 is that you don't have to test the same code over and over in each of your apps. You don't test the internals of ActiveRecord in each of your apps, so why would you test the internals of Authlogic? It's already been thoroughly tested for you. Focus on your application, and get rid of the noise by testing your application specific code and not generated code that you didn't write.

  5. You get to write your own code, just like you do for any other model. Meaning the code you write is specific to your application, the way you want it, and more importantly you understand it.

  6. You are not restricted to a single session. Think about Apple's, where they need you to authenticate a second time before changing your billing information. Why not just create a second session for this? It works just like your initial session. Then your billing controller can require an “ultra secure” session.

Authlogic can do all of this and much more, keep reading to see…

* Documentation: * Live example with OpenID “add on” & source code: * Tutorial: Authlogic basic setup: * Tutorial: Reset passwords with Authlogic the RESTful way: * Tutorial: Easily migrate from restful_authentication: * Tutorial: Upgrade passwords easily with Authlogic:

Before contacting me, please read:

If you find a bug or a problem please post it on lighthouse. If you need help with something, please use google groups. I check both regularly and get emails when anything happens, so that is the best place to get help.

Please do not email me directly with issues regarding Authlogic. This is an inefficient way to get help because it doesn't help people who have the same problem in the future.

Authlogic “add ons”

* Authlogic OpenID addon: * Authlogic LDAP addon:

If you create one of your own, please let me know about it so I can add it to this list.


You can find anything you want about Authlogic in the documentation, all that you need to do is understand the basic design behind it.

That being said, Authlogic is split into 2 main parts:

1. Authlogic::Session, which manages sessions.
2. Authlogic::ActsAsAuthentic, which adds in functionality to your ActiveRecord model.

Each of the above has its various sub modules that contain common logic. The sub modules are responsible for including everything related to it: configuration, class methods, instance methods, etc.

For example, if you want to timeout users after a certain period of inactivity, you would look in Authlogic::Session::Timeout. To help you out, I listed the following “publicly relevant” modules with short descriptions. For the sake of brevity, there are more modules than listed here, the ones not listed are more for internal use, but you can easily read up on them in the documentation.

Authlogic::ActsAsAuthentic sub modules

These modules are for the acts_as_authentic method you call in your model. It contains all code for the “model side” of the authentication.

  • Authlogic::ActsAsAuthentic::Base - Provides the acts_as_authentic class method and includes all of the submodules.

  • Authlogic::ActsAsAuthentic::Email - Handles everything related to the email field.

  • Authlogic::ActsAsAuthentic::LoggedInStatus - Provides handy named scopes and methods for determining if the user is logged in or out.

  • Authlogic::ActsAsAuthentic::Login - Handles everything related to the login field.

  • Authlogic::ActsAsAuthentic::MagicColumns - Handles everything related to the “magic” fields: login_count, failed_login_count, etc.

  • Authlogic::ActsAsAuthentic::Password - This one is important. It handles encrypting your password, salting it, etc. It also has support for transitioning password algorithms.

  • Authlogic::ActsAsAuthentic::PerishableToken - Handles maintaining the perishable token field, also provides a class level method for finding record using the token.

  • Authlogic::ActsAsAuthentic::PersistenceToken - Handles maintaining the persistence token. This is the token stored in cookies and sessions to persist the users session.

  • Authlogic::ActsAsAuthentic::RestfulAuthentication - Provides configuration options to easily migrate from the restful_authentication plugin.

  • Authlogic::ActsAsAuthentic::SessionMaintenance - Handles automatically logging the user in. EX: a new user registers, automatically log them in.

  • Authlogic::ActsAsAuthentic::SingleAccessToken - Handles maintaining the single access token.

  • Authlogic::ActsAsAuthentic::ValidationsScope - Allows you to scope validations, etc. Just like the :scope option for validates_uniqueness_of

Authlogic::Session sub modules

These modules are for the “session side” of authentication. They create a new domain for session logic, allowing you to create, destroy, and ultimately manage your sessions.

  • Authlogic::Session::BruteForceProtection - Disables accounts after a certain number of consecutive failed logins attempted.

  • Authlogic::Session::Callbacks - Your tools to extend, change, or add onto Authlogic. Lets you hook in and do just about anything you want. Start here if you want to write a plugin or add on for Authlogic

  • Authlogic::Session::Cookies - Authentication via cookies.

  • Authlogic::Session::Existence - Creating, saving, and destroying objects.

  • Authlogic::Session::HttpAuth - Authentication via basic HTTP authentication.

  • Authlogic::Session::Id - Allows sessions to be separated by an id, letting you have multiple sessions for a single user.

  • Authlogic::Session::MagicColumns - Maintains “magic” database columns, similar to created_at and updated_at for ActiveRecord.

  • Authlogic::Session::MagicStates - Automatically validates based on the records states: active?, approved?, and confirmed?. If those methods exist for the record.

  • Authlogic::Session::Params - Authentication via params, aka single access token.

  • Authlogic::Session::Password - Authentication via a traditional username and password.

  • Authlogic::Session::Persistence - Persisting sessions / finding sessions.

  • Authlogic::Session::Session - Authentication via the session, the controller session that is.

  • Authlogic::Session::Timeout - Automatically logging out after a certain period of inactivity.

  • Authlogic::Session::UnauthorizedRecord - Handles authentication by passing an ActiveRecord object.

  • Authlogic::Session::Validation - Validation / errors.

Miscellaneous modules

Miscellaneous modules that don't really belong solely to either the session or model aspect.

  • Authlogic::AuthenticatesMany - Responsible for allowing you to scope sessions to a parent record. Similar to a has_many and belongs_to relationship. This lets you do the same thing with sessions.

  • Authlogic::CryptoProviders - Contains various encryption algorithms that Authlogic uses, allowing you to choose your encryption method.

  • Authlogic::I18n - Acts JUST LIKE the rails I18n library, and provides internationalization to Authlogic.

  • Authlogic::Random - A simple class to generate random tokens.

  • Authlogic::TestCase - Various helper methods for testing frameworks to help you test your code.

  • Authlogic::Version - A handy class for determine the version of Authlogic in a number of ways.

Quick example

What if creating sessions worked like an ORM library on the surface…


What if your user sessions controller could look just like your other controllers…

class UserSessionsController < ApplicationController
  def new
    @user_session =

  def create
    @user_session =[:user_session])
      render :action => :new

  def destroy
    redirect_to new_user_session_url

As you can see, this fits nicely into the RESTful development pattern. What about the view…

<% form_for @user_session do |f| %>
  <%= f.error_messages %>
  <%= f.label :login %><br />
  <%= f.text_field :login %><br />
  <br />
  <%= f.label :password %><br />
  <%= f.password_field :password %><br />
  <br />
  <%= f.submit "Login" %>
<% end %>

Or how about persisting the session…

class ApplicationController
  helper_method :current_user_session, :current_user

    def current_user_session
      return @current_user_session if defined?(@current_user_session)
      @current_user_session = UserSession.find

    def current_user
      return @current_user if defined?(@current_user)
      @current_user = current_user_session && current_user_session.user

Install and use

1. Install the gem

Install the gem / plugin (recommended)

$ sudo gem install authlogic

Now add the gem dependency in your config:

# config/environment.rb
config.gem "authlogic"

Or you install this as a plugin (for older versions of rails)

script/plugin install git://

2. Create your session

Lets assume you are setting up a session for your User model.

Create your user_session.rb file:

$ script/generate session user_session

This will create a file that looks similar to:

# app/models/user_session.rb
class UserSession < Authlogic::Session::Base
  # configuration here, see sub modules of Authlogic::Session

3. Ensure proper database fields

The user model should have the following columns. The names of these columns can be changed with configuration. Better yet, Authlogic tries to guess these names by checking for the existence of common names. See the sub modules of Authlogic::Session for more details, but chances are you won't have to specify any configuration for your field names, even if they aren't the same names as below.

t.string    :login,               :null => false                # optional, you can use email instead, or both
t.string    :crypted_password,    :null => false                # optional, see below
t.string    :password_salt,       :null => false                # optional, but highly recommended
t.string    :persistence_token,   :null => false                # required
t.string    :single_access_token, :null => false                # optional, see Authlogic::Session::Params
t.string    :perishable_token,    :null => false                # optional, see Authlogic::Session::Perishability
t.integer   :login_count,         :null => false, :default => 0 # optional, see Authlogic::Session::MagicColumns
t.integer   :failed_login_count,  :null => false, :default => 0 # optional, see Authlogic::Session::MagicColumns
t.datetime  :last_request_at                                    # optional, see Authlogic::Session::MagicColumns
t.datetime  :current_login_at                                   # optional, see Authlogic::Session::MagicColumns
t.datetime  :last_login_at                                      # optional, see Authlogic::Session::MagicColumns
t.string    :current_login_ip                                   # optional, see Authlogic::Session::MagicColumns
t.string    :last_login_ip                                      # optional, see Authlogic::Session::MagicColumns

Notice the login and crypted_password fields are optional. If you prefer, you could use OpenID, LDAP, or whatever you want as your main authentication source and not even provide your own authentication system. I recommend providing your own as an option though. Your interface, such as the registration form, can dictate which method is the default. Lastly, adding 3rd party authentication methods should be as easy as installing an Authlogic “add on” gem. See “Authligic add ons” above.

4. Set up your model

Make sure you have a model that you will be authenticating with. Since we are using the User model it should look something like:

class User < ActiveRecord::Base
  acts_as_authentic do |c|
    c.my_config_option = my_value # for available options see documentation in: Authlogic::ActsAsAuthentic
  end # block optional

You are all set.

5. Next Steps

Here are some common next steps. They might or might not apply to you. For a complete list of everything Authlogic can do please read the documentation or see the sub module list above.

  1. Want to use another encryption algorithm, such as BCrypt? See Authlogic::ActsAsAuthentic::Password::Config

  2. Migrating from restful_authentication? See Authlogic::ActsAsAuthentic::RestfulAuthentication::Config

  3. Want to timeout sessions after a period if inactivity? See Authlogic::Session::Timeout

  4. Need to scope your sessions to an account or parent model? See Authlogic::AuthenticatesMany

  5. Need multiple session types in your app? Check out Authlogic::Session::Id

  6. Need to reset passwords or activate accounts? Use the perishable token. See Authlogic::ActsAsAuthentic::PerishableToken

  7. Need to give API access or access to a private feed? Use basic HTTP auth or authentication by params. See Authlogic::Session::HttpAuth or Authlogic::Session::Params

  8. Need to internationalize your app? See Authlogic::I18n

  9. Need help testing? See the Authlogic::TestCase

Interested in how it works?

Interested in how all of this all works? Basically a before filter is automatically set in your controller which lets Authlogic know about the current controller object. This “activates” Authlogic and allows Authlogic to set sessions, cookies, login via basic http auth, etc. If you are using your framework in a multiple thread environment, don't worry. I kept that in mind and made this thread safe.

From there it is pretty simple. When you try to create a new session the record is authenticated and then all of the session / cookie magic is done for you. The sky is the limit.

What's wrong with the current solutions?

You probably don't care, but I think releasing the millionth ruby authentication solution requires a little explanation.

I don't necessarily think the current solutions are “wrong”, nor am I saying Authlogic is the answer to your prayers. But, to me, the current solutions were lacking something. Here's what I came up with…

Generators are messy

Generators have their place, and it is not to add authentication to an app. It doesn't make sense. Generators are meant to be a starting point for repetitive tasks that have no sustainable pattern. Take controllers, the set up is the same thing over and over, but they eventually evolve to a point where there is no clear cut pattern. Trying to extract a pattern out into a library would be extremely hard, messy, and overly complicated. As a result, generators make sense here.

Authentication is a one time set up process for your app. It's the same thing over and over and the pattern never really changes. The only time it changes is to conform with newer / stricter security techniques. This is exactly why generators should not be an authentication solution. Generators add code to your application, once code crosses that line, you are responsible for maintaining it. You get to make sure it stays up with the latest and greatest security techniques. And when the plugin you used releases some major update, you can't just re-run the generator, you get to sift through the code to see what changed. You don't really have a choice either, because you can't ignore security updates.

Using a library that hundreds of other people use has it advantages. Probably one of the biggest advantages if that you get to benefit from other people using the same code. When Bob in California figures out a new awesome security technique and adds it into Authlogic, you get to benefit from that with a single update. The catch is that this benefit is limited to code that is not “generated” or added into your app. As I said above, once code is “generated” and added into your app, it's your responsibility.

Lastly, there is a pattern here, why clutter up all of your applications with the same code over and over?

Security gets outdated

Just as I stated in the above section, you can't stay up to date with your security since the code is generated and updating the plugin does nothing. If there is one thing you should stay up to date with, it's security. But it's not just the fact that there is no reasonable method for receiving updates. It's the fact that they tie you down to an encryption algorithm AND they use a bad one at that. Every single solution I've seen uses Sha1, which is joining the party with MD5. Sha1 is not as secure as it used to be. But that's the nature of algorithms, they eventually get phased out, which is fine. Everyone knows this, why not accommodate for this? Authlogic does this with the :transition_from_crypto_provider option. It takes care of transitioning all of your users to a new algorithm. Even better, it provides BCrypt as an option which should, in theory, never require you to switch since you can adjust the cost and make the encryption stronger. At the same time, still compatible with older passwords using the lower cost.

Why test the same code over and over?

I've noticed my apps get cluttered with authentication tests, and they are the same exact tests! This irritates me. When you have identical tests across your apps thats a red flag that code can be extracted into a library. What's great about Authlogic is that I tested it for you. You don't write tests that test the internals of ActiveRecord do you? The same applies for Authlogic. Only test code that you've written. Essentially testing authentication is similar to testing any another RESTful controller. This makes your tests focused and easier to understand.

Limited to a single authentication

I recently had an app where you could log in as a user and also log in as an employee. I won't go into the specifics of the app, but it made the most sense to do it this way. So I had two sessions in one app. None of the current solutions I found easily supported this. They all assumed a single session. One session was messy enough, adding another just put me over the edge and eventually forced me to write Authlogic. Authlogic can support 100 different sessions easily and in a clean format. Just like an app can support 100 different models and 100 different records of each model.

Too presumptuous

A lot of them forced me to name my password column as “this”, or the key of my cookie had to be “this”. They were a little too presumptuous. I am probably overly picky, but little details like that should be configurable. This also made it very hard to implement into an existing app.


I am not trying to “bash” any other authentication solutions. These are just my opinions, formulate your own opinion. I released Authlogic because I was “scratching my own itch”. It has made my life easier and I enjoy using it, hopefully it does the same for you.

Copyright © 2009 Johnson of Binary Logic(, released under the MIT license