🔑 api_keys – Secure API keys for your Rails app

Tip

🚀 Ship your next Rails app 10x faster! I've built RailsFast, a production-ready Rails boilerplate template that comes with everything you need to launch a software business in days, not weeks. Go check it out!

api_keys makes it simple to add secure, production-ready API key authentication to any Rails app. Generate keys, restrict scopes, auto-expire tokens, revoke tokens, gate endpoints. It also provides a self-serve dashboard for your users to self-issue and manage their API keys themselves. All tokens are hashed securely by default, and never stored in plaintext.

[ 🟢 Live interactive demo website ]

Check out my other 💎 Ruby gems: allgood · usage_credits · profitable · nondisposable

Installation

Add this line to your application's Gemfile:

gem "api_keys"

And then bundle install. After the gem is installed, run the generator and migration:

rails g api_keys:install
rails db:migrate

And you're done!

Quick Start

Just add has_api_keys to your desired model. For example, if you want your User records to have API keys, you'd have:

class User < ApplicationRecord
  has_api_keys
end

You can also customize how many maximum keys your users can have by passing a block to has_api_keys, like this:

class User < ApplicationRecord
  has_api_keys do
    max_keys 10 # only 10 active API keys per user allowed
    require_name true # always require users to set a name for each API key
  end
end

It'd work the same if you want your Organization or your Project records to have API keys.

Mount the dashboard engine so your users can self-serve API keys

The goal of api_keys is to allow you to turn your Rails app into an API platform with secure key authentication in minutes, as in: drop in this gem and you're pretty much done with API key management.

To achieve that, the gem provides a ready-to-go dashboard you can just mount in your routes.rb like this:

mount ApiKeys::Engine => '/settings/api-keys'

Default behavior (User-owned keys)

By default, the dashboard expects:

• A current_user method that returns the currently logged-in user
• An authenticate_user! method that ensures a user is logged in

This works out-of-the-box with Devise and most authentication solutions where User owns the API keys.

Custom owner models (Organization, Team, etc.)

If your API keys belong to a different model (e.g., Organization), you must configure the dashboard in your initializer:

# config/initializers/api_keys.rb
ApiKeys.configure do |config|
  # Tell the dashboard how to find the current API key owner
  config.current_owner_method = :current_organization
  
  # Tell the dashboard how to ensure the owner is authenticated
  config.authenticate_owner_method = :authenticate_organization!
end

These methods must exist in your ApplicationController (or wherever the engine is mounted). For example:

class ApplicationController < ActionController::Base
  def current_organization
    # Your logic to return the current organization
    @current_organization ||= Organization.find(session[:organization_id])
  end
  
  def authenticate_organization!
    redirect_to login_path unless current_organization
  end
end

Common scenarios

Organization with user membership:

# When organizations own keys but users manage them
config.current_owner_method = :current_organization
config.authenticate_owner_method = :require_organization_member!

Multi-tenant applications:

# When each tenant/account owns keys
config.current_owner_method = :current_account
config.authenticate_owner_method = :authenticate_account!

Team-based ownership:

# When teams own keys
config.current_owner_method = :current_team  
config.authenticate_owner_method = :ensure_team_access!

What the dashboard provides

Once configured, your users can:

• self-issue new API keys
• set expiration dates
• attach scopes / permissions to individual keys
• add and edit the key names
• revoke instantly
• see the status of all their keys

It provides an UI with everything you'd expect from an API keys dashboard, working right out of the box:

To make the experience between your app and the api_keys dashboard more seamless, you can configure a return_url and return_text so your users can quickly go back to your app or settings page (in the screenshot above, that's the "Home" links, text customizable)

You can check out the dashboard on the live demo website.

Customizing the Dashboard

The gem provides two levels of customization for the mounted dashboard:

Level 1: Use the stock dashboard (default)

Works out of the box with good defaults. No configuration needed.

Level 2: Override CSS variables

Tweak colors and spacing by overriding CSS variables in your application's stylesheet:

:root {
  --api-keys-primary-color: #your-brand-color;
  --api-keys-danger-color: #dc3545;
  --api-keys-success-color: #28a745;
  --api-keys-badge-secret-bg: #e7f1ff;
  --api-keys-badge-publishable-bg: #fef3cd;
  /* See layout file for all available variables */
}

Building Custom Integrations

If you need complete control over the UI (e.g., to match your design system with Tailwind, Bootstrap, etc.), you can build your own views and controllers while using the gem's model layer and helpers.

The gem provides a comprehensive set of helpers specifically designed for custom integrations. These patterns are battle-tested from real production integrations.

What You'll Need

A complete custom integration typically requires:

Component	Purpose
Initializer	Configure the gem + opt into form helpers
Routes	RESTful resources (~6 lines)
Controller	Handle CRUD operations (~90 lines)
Views	index, new, edit, success pages
Helper include	One line in ApplicationHelper

Quick Setup

1. Initializer (config/initializers/api_keys.rb):

# Include form builder extensions for cleaner forms
Rails.application.config.to_prepare do
  ActionView::Helpers::FormBuilder.include(ApiKeys::FormBuilderExtensions)
end

ApiKeys.configure do |config|
  config.current_owner_method = :current_organization
  config.authenticate_owner_method = :authenticate_organization!
  # ... other config
end

2. Routes (config/routes.rb):

namespace :settings do
  resources :api_keys, only: [:index, :new, :create, :edit, :update] do
    post :revoke, on: :member
    get :success, on: :collection
    post :create_publishable, on: :collection  # If using key types
  end
end

3. Helper (app/helpers/application_helper.rb):

module ApplicationHelper
  include ApiKeys::ViewHelpers
end

4. Controller - See the complete example below.

---

Complete Controller Example

Here's a production-ready controller (~90 lines) that handles all API key operations:

# app/controllers/settings/api_keys_controller.rb
module Settings
  class ApiKeysController < ApplicationController
    before_action :set_api_key, only: [:edit, :update, :revoke]
    before_action :set_available_scopes, only: [:new, :create, :edit, :update]

    def index
      @publishable_key = current_organization.api_keys.publishable.active.first
      @secret_keys = current_organization.api_keys.secret.active.order(created_at: :desc)
      @inactive_keys = current_organization.api_keys.secret.inactive.order(created_at: :desc)
    end

    def new
      @api_key = current_organization.api_keys.build(key_type: :secret)
    end

    def create
      @api_key = current_organization.create_api_key!(
        name: api_key_params[:name],
        key_type: :secret,
        scopes: api_key_params[:scopes],
        expires_at_preset: params.dig(:api_key, :expires_at_preset)
      )

      ApiKeys::TokenSession.store(session, @api_key)
      redirect_to success_settings_api_keys_path
    rescue ActiveRecord::RecordInvalid => e
      @api_key = e.record
      flash.now[:alert] = "Failed to create API key."
      render :new, status: :unprocessable_entity
    end

    def success
      @token = ApiKeys::TokenSession.retrieve_once(session)
      redirect_to settings_api_keys_path, alert: "Token can only be shown once." and return if @token.blank?
    end

    def edit
    end

    def update
      if @api_key.update(api_key_params)
        redirect_to settings_api_keys_path, notice: "API key updated."
      else
        flash.now[:alert] = "Failed to update API key."
        render :edit, status: :unprocessable_entity
      end
    end

    def create_publishable
      unless current_organization.can_create_api_key?(key_type: :publishable)
        redirect_to settings_api_keys_path, alert: "You already have a publishable key."
        return
      end

      current_organization.create_api_key!(name: "SDK Key", key_type: :publishable)
      redirect_to settings_api_keys_path, notice: "Publishable key created!"
    rescue ActiveRecord::RecordInvalid => e
      redirect_to settings_api_keys_path, alert: "Failed to create key."
    end

    def revoke
      if @api_key.revocable?
        @api_key.revoke!
        redirect_to settings_api_keys_path, notice: "API key revoked."
      else
        redirect_to settings_api_keys_path, alert: "This key cannot be revoked."
      end
    end

    private

    def set_api_key
      @api_key = current_organization.api_keys.find(params[:id])
    end

    def set_available_scopes
      @available_scopes = current_organization.available_api_key_scopes
    end

    def api_key_params
      params.require(:api_key).permit(:name, scopes: [])
    end
  end
end

---

Model Scopes

Filter keys by type and status:

# By key type (when using key_types feature)
@org.api_keys.publishable          # Only publishable keys
@org.api_keys.secret               # Secret keys (and legacy keys without type)

# By status
@org.api_keys.active               # Not revoked and not expired
@org.api_keys.inactive             # Revoked or expired
@org.api_keys.expired              # Past expiration date
@org.api_keys.revoked              # Manually revoked

# Chain them
@org.api_keys.publishable.active
@org.api_keys.secret.inactive.order(created_at: :desc)

---

Owner Instance Methods

Methods available on any model with has_api_keys:

# Get available scopes for forms
@available_scopes = current_org.available_api_key_scopes
# Returns owner-specific scopes, or falls back to global config

# Check if owner can create a key (respects limits)
current_org.can_create_api_key?(key_type: :publishable)
# => false if limit reached

# Create a key with all options
@api_key = current_org.create_api_key!(
  name: "My Key",
  key_type: :secret,                    # or :publishable
  scopes: ["read", "write"],            # Blank values auto-removed
  expires_at: 30.days.from_now,         # Explicit date
  expires_at_preset: "30_days",         # OR use preset (takes precedence)
  environment: :live,                   # Defaults to current_environment
  metadata: { team: "backend" }         # Optional JSON metadata
)

---

API Key Instance Methods

Methods available on ApiKeys::ApiKey instances:

# Token (only available immediately after creation)
@api_key.token                    # => "sk_live_abc123..." (plaintext, once only)

# Display
@api_key.masked_token             # => "sk_live_••••abc1" (safe for UI)
@api_key.viewable_token           # => full token if public key type, nil otherwise

# Status checks
@api_key.active?                  # => true if not revoked and not expired
@api_key.expired?                 # => true if past expires_at
@api_key.revoked?                 # => true if manually revoked
@api_key.revocable?               # => false for non-revocable key types

# Type checks (when using key_types)
@api_key.public_key_type?         # => true if token can be viewed again
@api_key.key_type                 # => "publishable", "secret", or nil
@api_key.environment              # => "test", "live", or nil

# Actions
@api_key.revoke!                  # Revoke the key (raises if not revocable)

# Scopes
@api_key.scopes                   # => ["read", "write"]
@api_key.allows_scope?("read")    # => true

# Metadata
@api_key.name                     # => "Production Server"
@api_key.created_at
@api_key.expires_at
@api_key.last_used_at
@api_key.requests_count           # If tracking enabled

---

Token Session Helper

Manages the "show token once" pattern for secret keys:

# Store token after creation
ApiKeys::TokenSession.store(session, @api_key)

# Retrieve and clear (returns nil on subsequent calls)
@token = ApiKeys::TokenSession.retrieve_once(session)

# With custom session key (if managing multiple token types)
ApiKeys::TokenSession.store(session, @api_key, key: :my_custom_key)
@token = ApiKeys::TokenSession.retrieve_once(session, key: :my_custom_key)

---

Expiration Options Helper

For building expiration dropdowns:

# Get options for select
ApiKeys::ExpirationOptions.for_select
# => [["No Expiration", "no_expiration"], ["7 days", "7_days"], ["30 days", "30_days"], ...]

# Get default value
ApiKeys::ExpirationOptions.default_value
# => "no_expiration"

# Parse a preset to a date
ApiKeys::ExpirationOptions.parse("30_days")
# => 30.days.from_now

ApiKeys::ExpirationOptions.parse("no_expiration")
# => nil

# Exclude "no expiration" option
ApiKeys::ExpirationOptions.for_select(include_no_expiration: false)

---

Form Builder Extensions (Opt-in)

Add to your initializer to enable:

Rails.application.config.to_prepare do
  ActionView::Helpers::FormBuilder.include(ApiKeys::FormBuilderExtensions)
end

api_key_expiration_select

Renders a select dropdown with all expiration presets:

<%# Basic usage %>
<%= form.api_key_expiration_select %>

<%# With CSS classes (Tailwind example) %>
<%= form.api_key_expiration_select(class: "w-full px-4 py-3 border rounded-lg") %>

<%# With custom default selection %>
<%= form.api_key_expiration_select(selected: "30_days") %>

api_key_scopes_checkboxes

Renders scope checkboxes with a block for custom markup:

<%# With block - you control the HTML, gem handles the logic %>
<%= form.api_key_scopes_checkboxes(@available_scopes) do |scope, checked| %>
  <label class="flex items-center gap-2">
    <%= check_box_tag "api_key[scopes][]", scope, checked, class: "rounded" %>
    <code><%= scope %></code>
  </label>
<% end %>

<%# For new records, all scopes are checked by default %>
<%# For existing records, only the key's current scopes are checked %>

<%# Override checked state %>
<%= form.api_key_scopes_checkboxes(@scopes, checked: :none) do |scope, checked| %>
  ...
<% end %>

<%# checked options: :all, :none, or an array of specific scopes %>

api_key_token_data

Returns structured data for building token display UIs:

<% data = form.api_key_token_data %>
<code><%= data[:masked] %></code>

<% if data[:viewable] %>
  <button data-token="<%= data[:full] %>">Copy</button>
<% end %>

<%# Returns: { masked:, full:, viewable:, type:, environment: } %>

---

View Helpers

Include in your ApplicationHelper:

module ApplicationHelper
  include ApiKeys::ViewHelpers
end

Status Helpers

<%# Get status as symbol %>
<%= api_key_status(@key) %>
<%# => :active, :expired, or :revoked %>

<%# Get human-readable label %>
<%= api_key_status_label(@key) %>
<%# => "Active", "Expired", or "Revoked" %>

<%# Get full status info for styling %>
<% info = api_key_status_info(@key) %>
<span class="<%= info[:color] == :green ? 'bg-green-100' : 'bg-red-100' %>">
  <%= info[:label] %>
</span>
<%# Returns: { status: :active, label: "Active", color: :green } %>
<%# Colors: :green (active), :red (revoked), :gray (expired) %>

Type & Environment Helpers

<%# Key type label %>
<%= api_key_type_label(@key) %>
<%# => "Publishable", "Secret", or nil %>

<%# Environment label %>
<%= api_key_environment_label(@key) %>
<%# => "Test", "Live", or "Default" %>

<%# Type checks %>
<%= api_key_publishable?(@key) %>  <%# => true/false %>
<%= api_key_secret?(@key) %>       <%# => true/false %>

<%# Get environment from a token string (useful on success page) %>
<%= api_key_environment_from_token(@token) %>
<%# => :test, :live, or nil %>

<%= api_key_environment_label_from_token(@token) %>
<%# => "Test mode", "Live mode", or "Default" %>

---

View Examples

Index Page (Key List)

<%# Publishable key section %>
<% if @publishable_key %>
  <code><%= @publishable_key.viewable_token || @publishable_key.masked_token %></code>
  <span><%= api_key_environment_label(@publishable_key) %> mode</span>
<% else %>
  <%= button_to create_publishable_settings_api_keys_path, method: :post do %>
    Create Publishable Key
  <% end %>
<% end %>

<%# Secret keys table %>
<% @secret_keys.each do |key| %>
  <tr>
    <td><%= key.name || "Unnamed key" %></td>
    <td><code><%= key.masked_token %></code></td>
    <td><%= api_key_status_label(key) %></td>
    <td>
      <%= link_to "Edit", edit_settings_api_key_path(key) %>
      <%= button_to "Revoke", revoke_settings_api_key_path(key), method: :post %>
    </td>
  </tr>
<% end %>

New/Edit Form

<%= form_with(model: @api_key, url: settings_api_keys_path) do |form| %>
  <%# Name %>
  <%= form.text_field :name, placeholder: "e.g., Production Server" %>

  <%# Expiration (new keys only) %>
  <%= form.api_key_expiration_select(class: "form-select") %>

  <%# Scopes %>
  <%= form.api_key_scopes_checkboxes(@available_scopes) do |scope, checked| %>
    <label>
      <%= check_box_tag "api_key[scopes][]", scope, checked %>
      <%= scope %>
    </label>
  <% end %>

  <%= form.submit %>
<% end %>

Success Page (Show Token Once)

<% if @token.present? %>
  <input type="text" value="<%= @token %>" readonly>
  <button data-copy="<%= @token %>">Copy</button>
  <span><%= api_key_environment_label_from_token(@token) %></span>

  <p>This key will only be shown once. Copy it now!</p>
<% else %>
  <p>Token already shown. Create a new key if needed.</p>
  <%= link_to "Create New Key", new_settings_api_key_path %>
<% end %>

---

Best Practices

Based on real production integrations:

1. Use RESTful routes - resources :api_keys with member/collection actions, not custom route definitions.

2. Separate form-only params - Access expires_at_preset via params.dig(:api_key, :expires_at_preset) rather than including it in strong params (it's not a model attribute).

3. Use before_action for shared setup - Extract @available_scopes to a before_action rather than setting it in multiple actions.

4. Let validations handle errors - Rescue ActiveRecord::RecordInvalid and re-render the form rather than pre-checking everything.

5. Use the gem's helpers consistently - Use api_key_status_label(key) everywhere rather than hardcoding "Active" in some places.

6. Check limits before showing UI - Use can_create_api_key?(key_type:) to conditionally show/hide create buttons.

7. Keep controllers thin - The gem handles token generation, hashing, scope filtering, and validation. Your controller just orchestrates.

See the "How it works" section below for additional model methods.

How it works

Issuing new API keys

If you want to write your own front-end instead of using the provided dashboard, or just want to issue API keys at any point, you can do it with create_api_key!:

@api_key = @user.create_api_key!(
  name: "my-key",
  scopes: "['read', 'write']",
  expires_at: 42.days.from_now
)

# Get the plaintext token only available upon creation
plaintext_token = @api_key.token
# => ak_123abc...

For security reasons, the gem does not store the generated key in the database.

We only store a secure hash (SHA256 by default), so the API key / API token itself is only available in plaintext immediately after creation, as @api_key.token – the .token method won't work any other time.

With this token, your users can make calls to your endpoints by attaching it as an "Authorization: Bearer ak_123abc..." in their HTTP calls headers, like this:

curl -X GET -H "Authorization: Bearer ak_123abc..."   "http://example.com/api/endpoint"

Listing all keys for users

Of course, you can list all API keys for any record like this:

  @user.api_keys

You can filter by active keys, expired keys, revoked keys:

  @user.api_keys.active
  @user.api_keys.expired
  @user.api_keys.revoked
  @user.api_keys.inactive # expired or revoked

Useful API key methods

Check if an API key is still active and therefore allowed to perform actions:

@api_key.active?
# => true

Or expired:

@api_key.expired?
# => false

You can revoke (disable, make inactive) any API key at any point like this:

@api_key.revoke!

And you can check if an API key is revoked like this:

@api_key.revoked?
# => true

And for any API key, you can always display a safe, user-friendly masked token to display on user interfaces so users can easily identify their keys:

@api_key.masked_token
# => "ak_demo_••••yZn9"

Scopes: define and verify API Key permissions

Users can limit what each API key does by selecting scopes, and you can define those scopes.

In the config/initializers/api_keys.rb initializer generated when you installed the gem, you'll find an option to define global scopes:

config.default_scopes = ["read", "write"]

These will be the available permissions you'll see, for example, in the API Keys dashboard:

You can also define per-model scopes by passing the option to the has_api_keys block, which overrides global defaults:

class User < ApplicationRecord
  has_api_keys do
    max_keys 10
    default_scopes %w[read write admin]
  end
end

You can get as granular with your scopes as you'd like, think for example AWS-like strings of the form: "s3:GetObject" – how you set this up is up to you! Scopes take any string: we recommend sticking to simple verbs ("read", "write") or "resource:action" (case-sensitive!)

You can check if an API key is allowed to do actions by checking its scopes:

@api_key.allows_scope?("read")
# => true

Controllers: secure your API endpoints

To add the api_keys functionality to your controllers, just use the ApiKeys::Controller concern and you'll have all controller methods available:

class ApiController < ApplicationController
  include ApiKeys::Controller # provides authenticate_api_key! and current_api_key_owner
end

With this, you get the authenticate_api_key! and current_api_key_owner methods, which come in handy to build your key-gated actions.

Require an API key for an endpoint

If you just want to check the presence of a valid (active, non-expired, non-revoked) API key for an endpoint, you can do:

before_action :authenticate_api_key!

And of course, if you want to have unauthenticated endpoints:

before_action :authenticate_api_key!, except: [:unauthenticated_endpoint]

authenticate_api_key! will return 401 Unauthenticated for anything that's not a valid API key.

It will also load the valid API key, if any, to a current_api_key variable, that returns an API Key object (ApiKeys::ApiKey) on which you can call all the methods we've outlined above, and access any attribute, like:

current_api_key.expires_at
# => 2025-05-25 05:25:05.250525000 UTC +00:00

If the API key has an owner, you can also access it either with current_api_key.owner or with the helper method current_api_key_owner

For example, if the owner of the API key is a User, you might do something like:

current_api_key_owner.email
# => john.doe@example.com

Require a scope for an endpoint

You can require a specific scope for any endpoint like:

authenticate_api_key!(scope: "write")

It may be cleaner if you pass it as a Proc to before_action – and it may result in better-organized code if you do it endpoint-per-endpoint, immediately before each method definition, like this:

before_action -> { authenticate_api_key!(scope: "write") }, only: [:write_action]
def write_action
  # We'll only get here if the API key is active AND it has the right scope, so execute the actual logic of the endpoint and return success:
  render json: {
    # Your success JSON...
  }, status: :ok
end

Rate limit your API endpoints

Rails 8 introduced the native, built-in rate_limit to easily rate limit your endpoints, so Rack::Attack is no longer necessary! While this is not an api_keys feature per se, I thought it'd be nice to include an example here because it pairs so well with api_keys.

For example, if you want to rate limit an endpoint to only accept 2 requests each 10 seconds, per API key, you'd do something like:

before_action -> { authenticate_api_key! }, only: [:rate_limited_action]
rate_limit to: 2, within: 10.seconds,
            by: -> { current_api_key&.id }, # Limit per API key ID
            with: -> { render json: { error: "rate_limited", message: "Too many requests (max 2 per 10 seconds per key). Please wait." }, status: :too_many_requests },
            only: [:rate_limited_action]
def rate_limited_action
  render json: {
    # Success JSON
  }, status: :ok
end

This rate_limit feature depends on Rails 8+ and an active, well-configured cache store, like solid_cache, which comes by default in Rails 8.

If you're still on early versions of Rails, you can still use api_keys! No need to implement rate_limit – just an idea if you're already on Rails 8!

Configuration and settings

The gem installation creates an initializer at config/initializers/api_keys.rb

The default initializer is self-explanatory and self-documented, please consider spending a bit of time reading through it if you want to fine-tune the gem.

Token prefixes

API keys are generated with a prefix followed by random characters:

ak_7Hq2mJ6vK9pRs3xYz9...
^^        ^^^^^^^^^^^
prefix    random part

The prefix makes it easy to identify API keys at a glance (in logs, code reviews, etc.) and helps services like GitHub detect leaked credentials.

Simple mode (default): All keys use the same prefix from token_prefix:

config.token_prefix = -> { "myapp_" }  # → myapp_abc123...

Key types mode: When you configure key_types, different key types get different prefixes based on their type and environment (Stripe-style):

# With key_types configured, prefixes come from the type configuration:
# publishable + test → pk_test_abc123...
# secret + live → sk_live_xyz789...

Prefix precedence

When using key types, here's how the prefix is determined:

key_types Config	key_type Param	Resulting Prefix
{} (disabled)	any	Uses token_prefix → "ak_..."
Configured	nil	Uses token_prefix → "ak_..."
Configured	:publishable	Uses type config → "pk_test_..."
Configured	:secret	Uses type config → "sk_live_..."

In short: token_prefix is only used when key types are not configured OR when creating a key without specifying a key_type. When you specify both key_types config and a key_type parameter, the prefix comes entirely from the key type configuration.

See the Key Types section below for full details.

Some highlights:

Accept API keys via query params instead of Authentication HTTP headers

By default, the api_key gem expects API keys to come exclusively as HTTP Authentication Bearer tokens, for security purposes. But you can allow users to make requests to your endpoints with the API key token passed as a URL query param too, like this:

https://example.com/api/endpoint?api_key=ak_123abc...

This is not recommended security-wise because you'll be leaking API tokens everywhere in your logs, but if you want to enable this, just set the query param name you're expecting the API key token to be in:

config.query_param = "api_key"

Changing the hashing function to bcrypt for maximum security

By default, the api_keys gem hashes tokens using sha256, which is the industry standard for API keys (used by Stripe, GitHub, AWS). SHA256 is secure for high-entropy tokens because the 192 bits of randomness make brute-force attacks computationally infeasible. We use SHA256 and not other hasing algorithms for fast token lookup and low-latency API authentication.

If you need slower, password-grade hashing (e.g., for extremely sensitive tokens), you can switch to bcrypt:

config.hash_strategy = :bcrypt

Note: bcrypt is ~50–100x slower than SHA256. For most API use cases, sha256 is more than sufficient.

sha256 has O(1) lookup, bcrypt doesn't. This means that if you switch to bcrypt, you may observe ~100ms lags on every API call, for every token auth that's not cached.

For 99% of APIs, sha256 is more than secure enough — and far better for performance.

Increase cache TTL

We cache token lookups to improve performance, especially for repeated requests. This keeps bcrypt and sha256 strategies fast under load.

By default, we use a 5-second TTL, which offers a strong balance: most requests benefit from caching, while revoked keys stop working almost immediately.

If security is your top priority (e.g. rapid revocation after suspected key compromise), you can disable caching entirely:

config.cache_ttl = 0.seconds # disables caching

If performance matters more than real-time revocation, increase the TTL to reduce DB hits:

config.cache_ttl = 2.minutes # boosts performance at cost of slower revocation

⚠️ Security note: Revoked keys may remain valid for up to cache_ttl. For strict real-time revocation, set cache_ttl = 0.

Callbacks: analytics, logging, usage monitoring & auditing

The gem offers two callbacks that get executed every single time an API key is checked and authenticated (through authenticate_api_key! in controllers, for example)

You can define logic for them:

config.before_authentication = ->(request) { Rails.logger.info "Authenticating request: #{request.uuid}" }

config.after_authentication = ->(result) { MyAnalytics.track_auth(result) }

This is especially useful if you want to build custom monitoring, usage tracking or auditing systems on top of the api_keys gem.

Since these callbacks get called every single time an endpoint request is made, we can't just execute the code synchronously, blocking the thread and making the endpoint lag. Instead, we enqueue an async job that process the callback code, however long it is. You can configure which queue these jobs get enqueued to.

The downside of this, of course, is that callbacks will only work if you have a valid, well-configured Active Job backend for your Rails app, like Sidekiq or solid_queue, which comes by default in Rails 8. If Active Job is not well configured, well, your callbacks just won't get executed.

There's also a track_requests_count config option that you can turn on so the gem keeps track of how many requests has each API key made. When this is on, you may access the count like this:

@api_key.requests_count
# => 4567

But again, this is turned off by default for performance purposes, and depends on having a working, well-configured Active Job backend.

Key Types: Stripe-style Publishable & Secret Keys

For applications that distribute software with embedded API keys (desktop apps, mobile apps, CLI tools), you may want to differentiate between key types with different permission levels. The api_keys gem supports Stripe-style publishable/secret key types with optional test/live environment isolation.

Why Key Types?

When you distribute software with an embedded API key, that key can potentially be extracted by malicious users. Key types solve this by letting you create:

• Publishable keys (pk_test_..., pk_live_...): Safe to embed in distributed apps. Limited permissions (e.g., can only validate licenses, not issue new ones). Cannot be revoked (to prevent accidentally breaking all deployed apps).

• Secret keys (sk_test_..., sk_live_...): Full access, meant for server-side use only. Can be revoked anytime.

Configuration

Enable key types in your initializer:

# config/initializers/api_keys.rb
ApiKeys.configure do |config|
  config.key_types = {
    publishable: {
      prefix: "pk",                    # Token prefix → pk_test_, pk_live_
      permissions: %w[read validate],  # Scope ceiling (max permissions allowed)
      revocable: false,                # Cannot be revoked or deleted
      limit: 1                         # Max 1 per owner per environment
    },
    secret: {
      prefix: "sk",
      permissions: :all                # No scope restrictions
      # revocable defaults to true, limit defaults to nil (unlimited)
    }
  }

  config.environments = {
    test: { prefix_segment: "test" },  # → pk_test_, sk_test_
    live: { prefix_segment: "live" }   # → pk_live_, sk_live_
  }

  # Detect current environment automatically
  config.current_environment = -> { Rails.env.production? ? :live : :test }

  # Enable strict environment isolation (test keys fail in prod, live keys fail in dev)
  config.strict_environment_isolation = true
end

Creating Typed Keys

# Create a publishable key (limited permissions, cannot be revoked)
pk = user.create_api_key!(
  name: "Production App",
  key_type: :publishable,
  environment: :live  # Optional, defaults to current_environment
)
pk.token  # => "pk_live_abc123..."

# Create a secret key (full access)
sk = user.create_api_key!(
  name: "Admin Dashboard",
  key_type: :secret
)
sk.token  # => "sk_test_xyz789..."

Scope Ceiling

When a key type has limited permissions, any scopes you pass are filtered:

# Publishable keys can only have read/validate permissions
pk = user.create_api_key!(
  key_type: :publishable,
  scopes: %w[read validate issue_license admin]  # Tries to request all
)
pk.scopes  # => ["read", "validate"]  # Only allowed scopes kept

# Secret keys with permissions: :all keep everything
sk = user.create_api_key!(
  key_type: :secret,
  scopes: %w[read validate issue_license admin]
)
sk.scopes  # => ["read", "validate", "issue_license", "admin"]

Non-Revocable Keys

Keys with revocable: false protect against accidental deletion:

pk = user.create_api_key!(key_type: :publishable)

pk.revocable?  # => false
pk.revoke!     # Raises ApiKeys::Errors::KeyNotRevocableError
pk.destroy!    # Raises ApiKeys::Errors::KeyNotRevocableError

The dashboard UI automatically hides the revoke button for non-revocable keys.

Public Keys (Viewable Tokens)

The Problem: Non-Revocable Key Lockout

Non-revocable keys create a potential UX nightmare: if a user creates a publishable key, doesn't copy it immediately, and closes the page—they're locked out. The token is gone forever (we only store the hash), and they can't delete the key to create a new one (it's non-revocable). They're stuck with a useless key slot they can never use or remove.

This is especially problematic when combined with limit: 1, which restricts users to a single publishable key per environment. A user who loses their token would be permanently locked out of creating publishable keys.

The Solution: Storing Public Keys

For publishable keys—which are designed to be embedded in client-side code and distributed apps—there's no security benefit to hiding the token. These keys are meant to be public! Stripe, for example, lets you view your publishable key anytime in the dashboard.

The public: true option stores the plaintext token in metadata so users can view it again:

config.key_types = {
  publishable: {
    prefix: "pk",
    permissions: %w[read validate],
    revocable: false,
    public: true,   # Store token for later viewing
    limit: 1
  },
  secret: {
    prefix: "sk",
    permissions: :all
    # public: false (default) - NEVER store secret keys!
  }
}

Security: Why This is Safe

Important

The public option only works when BOTH conditions are met:

• public: true is set in the key type configuration
• revocable: false is set (non-revocable keys only)

This double-check is a deliberate safety measure:

1. Secret keys are NEVER stored — Even if you accidentally set public: true on a secret key type, the gem checks for revocable: false as well. Secret keys are revocable by default, so they're protected.

2. Revocable keys are NEVER stored — If a key can be revoked, users can always delete it and create a new one. There's no lockout risk, so no need to store the token.

3. Only truly public keys are stored — Publishable keys with limited permissions, designed for client-side embedding, are the only keys that get stored. These tokens provide no security benefit when hidden—they're meant to be distributed.

Warning

⚠️ Never set public: true on secret keys or any key type with sensitive permissions. The gem prevents this by requiring revocable: false, but you should also never configure it that way.

When a key is public, the dashboard shows a "Show" button to reveal the full token:

pk = user.create_api_key!(key_type: :publishable)
pk.public_key_type?  # => true
pk.viewable_token    # => "pk_test_abc123..." (the full token)

sk = user.create_api_key!(key_type: :secret)
sk.public_key_type?  # => false
sk.viewable_token    # => nil (not stored)

Environment Isolation

With strict_environment_isolation = true, keys can only authenticate in their matching environment:

# In production (current_environment returns :live)
# A test key will fail authentication with error_code: :environment_mismatch

This prevents accidentally using test keys in production (or vice versa).

Key Limits

The limit option restricts how many keys of a type can exist per owner per environment:

# With limit: 1 for publishable keys
user.create_api_key!(key_type: :publishable, environment: :test)  # Works
user.create_api_key!(key_type: :publishable, environment: :test)  # Raises validation error

# But can have one per environment
user.create_api_key!(key_type: :publishable, environment: :live)  # Works

Sandbox/Live Naming

You can use any environment names. For Stripe-style sandbox:

config.environments = {
  sandbox: { prefix_segment: "test" },  # → pk_test_
  live: { prefix_segment: "live" }      # → pk_live_
}

Upgrading Existing Installations

If you're adding key types to an existing installation, run the migration generator:

rails g api_keys:add_key_types
rails db:migrate

Existing keys without key_type/environment continue to work normally (backwards compatible).

Enterprise-ready by design

The api_keys gem ships with:

• Flexible storage
• Async hooks
• ActiveJob support
• Polymorphic ownership (User, Org, etc.)
• Custom scopes
• Production caching
• Tracking of last time each key was used
• Usage tracking
• SHA256 fallback

Making it enterprise-ready, built with extensibility and compliance in mind.

Roadmap

• Automatic rotation policy helpers
• Key-pair / HMAC option

Demo Rails app

There's a demo Rails app showcasing the features in the api_keys gem under test/dummy. It's currently deployed to apikeys.rameerez.com. If you want to run it yourself locally, you can just clone this repo, cd into the test/dummy folder, and then bundle and rails s to launch it. You can examine the code of the demo app to better understand the gem.

Testing

Run the test suite with bundle exec rake test

Development

After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install.

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/rameerez/api_keys. Our code of conduct is: just be nice and make your mom proud of what you do and post online.

License

The gem is available as open source under the terms of the MIT License.