{"id":6953,"date":"2017-09-18T09:45:58","date_gmt":"2017-09-18T16:45:58","guid":{"rendered":"https:\/\/www.backerkit.com\/blog\/?p=6953"},"modified":"2020-02-21T00:40:42","modified_gmt":"2020-02-21T08:40:42","slug":"using-rails-messageverifier-for-stateless-token-management","status":"publish","type":"post","link":"https:\/\/www.backerkit.com\/blog\/using-rails-messageverifier-for-stateless-token-management\/","title":{"rendered":"Using Rails’ MessageVerifier for Stateless Token Management"},"content":{"rendered":"

Many web applications have the need to send links to users that allow the user to perform an action without logging in. Examples include password reset and confirming an email address. These links need to embed some kind of identifying information so the server can discern which user is performing the action. If the action is sensitive, the link should also include some amount of obfuscation so the URLs cannot be guessed or generated by nefarious actors.<\/p>\n

We have a few ways to generate links that serve this purpose. Many applications start with something like Rails’ has_secure_token<\/a>. This helper wraps up the logic to generate and persist tokens in a datastore. This approach is well understood and easy to reason about.<\/p>\n

What are some of the downsides of storing tokens on the server? Storing the tokens in plaintext means if an attacker gets access to the application’s database, all of the stored tokens are exposed. Hashing (or digesting) the tokens asymmetrically fixes this issue but we still have to persist and protect this data.<\/p>\n

What if we don’t need to persist the token at all? What if we could generate a token, send it out in a link, and then verify it when it gets sent back to us? In this way, we don’t have to store the tokens, which means there is less to protect.<\/p>\n

We can achieve this stateless approach with encoded and signed tokens. Rails provides a mechanism to generate and verify tokens via ActiveSupport::MessageEncryptor<\/code><\/a> and ActiveSupport::MessageVerifier<\/code><\/a>.<\/p>\n

We recently implemented stateless tokens in our app so users could confirm subscriptions to mailing lists. Below we’ll go through some code to get us there.<\/p>\n

Let’s look at some code<\/h2>\n

We have a controller with a create<\/code> action that allows a user to submit an email address and a confirmations<\/code> action that verifies a submitted token.<\/p>\n

class SubscriptionsController < ApplicationController\n  def create\n    subscription = Subscription.build(email: subscription_params[:email])\n\n    if subscription.save\n      SubscriptionsMailer.confirm_subscription(subscription.id).deliver_later  \n      redirect_to subscriptions_path\n    else\n      redirect_to subscriptions_path\n    end\n  end\n\n  def confirmations\n    subscription = Subscription.verify_token_and_find(token: params[:token])\n\n    if subscription.present?\n      subscription.touch(:confirmed_at)\n      flash[:notice] = \"Thanks for subscribing!\"\n    else\n      flash[:error] = \"Oh no! Your token is not valid.\"\n    end\n\n    redirect_to subscriptions_path\n  end\n\n  private\n\n  def subscription_params\n    params.require(:subscription).permit(:email)\n  end\nend\n<\/code><\/pre>\n
And our model looks like this:<\/p>\n
class Subscription < ApplicationRecord\n  CONFIRMATION_IN_DAYS = 7\n  scope :confirmed, lambda { where.not(confirmed_at: nil) }\n  validates :email, uniqueness: true\n\n  def generate_token(expiration_in_days: CONFIRMATION_IN_DAYS)\n    expiration = Time.current + expiration_in_days.days\n    token_values = { id: id, expiration: expiration }\n    self.class.encryptor.encrypt_and_sign(token_values)\n  end\n\n  def self.verify_token_and_find(token:)\n    begin\n      data = encryptor.decrypt_and_verify(token)\n      given_expiration = data[:expiration]\n\n      if given_expiration < Time.current\n        return nil\n      end\n\n      find(data[:id])\n    rescue ActiveSupport::MessageVerifier::InvalidSignature\n      nil\n    end\n  end\n\n  def self.encryptor\n    key_password_for_mailing_list = ENV.fetch('KEY_PASSWORD_FOR_SUBSCRIPTION')\n    SUBSCRIPTION_ENCRYPTOR_KEY = ActiveSupport::KeyGenerator\n      .new(key_password_for_mailing_list)\n      .generate_key(salt, 32)\n\n    ActiveSupport::MessageEncryptor.new(SUBSCRIPTION_ENCRYPTOR_KEY)\n  end\nend\n<\/code><\/pre>\n
Our mailer is relatively straightforward except for the line where we call subscription.generate_token<\/code>, which does the heavy lifting for generating and signing our token:<\/p>\n
class SubscriptionsMailer < ActionMailer::Base\n  def confirm_subscription(subscription_id)\n    subscription = Subscription.find(subscription_id)\n    @link = confirmation_url(subscription: subscription)\n\n    mail(\n      from: \"support@yourwebsite.com\",\n      subject: \"Please Confirm Your Subscription\",\n      to: subscription.email\n    ) do |format|\n      format.text\n      format.html\n    end\n  end\n\n  private\n\n  def confirmation_url(subscription:)\n    subscriptions_url(token: subscription.generate_token)\n  end\nend\n<\/code><\/pre>\n
What’s the catch?<\/h2>\n
One downside of this approach is the need to manage another key, which involves protecting it (likely via using environment variables) and being able to rotate the key in an operationally simple manner. There is not a great option out of the box to manage these workflows but it’s worth considering the costs and benefits of not storing this data.<\/p>\n
Conclusion<\/h2>\n
We wanted to find a way to avoid storing keys in our database for security and storage reasons and this approach serves our purpose. Expiring, rotating, and protecting keys still require forethought, but that’s nothing new.<\/p>\n
Want to learn more?<\/h2>\n