Skip to content
rab edited this page Oct 18, 2012 · 3 revisions

Theoretical Framework

OmniAuth works on the principle that every authentication system can essentially be boiled down into two "phases".

The Request Phase

In the Request Phase, we request information from the user that is necessary to complete authentication. This information may be POSTed to a URL or performed externally through an authentication process such as OpenID.

The Callback Phase

In the Callback Phase, we receive an authenticated unique identifier that can differentiate this user from other users of the same authentication system. Additionally, we may provide user information that can be automatically harvested by the application to fill in the details of the authenticating user.

Practical Implementation

These middleware all follow a consistent pattern in that they initiate the request phase when the browser is directed (with additional information in some cases) to /auth/provider_name. They then all end their authentication process by calling the main Rack application at the endpoint /auth/provider_name/callback with request parameters pre-populated with an auth hash containing:

  • 'provider' - The provider name
  • 'uid' - The unique identifier of the user
  • 'credentials' - A hash of credentials for access to protected resources from the authentication provider (OAuth, Facebook)
  • 'info' - Additional information about the user

What this means is that, for all intents and purposes, your application needs only be concerned with directing the user to the request phase and managing user information and session upon authentication callback. All of the implementation details of the different authentication providers can be treated as a black box.