Broken Authentication in Rails with Jwt Tokens

Broken authentication in Ruby on Rails when using JWT tokens typically arises from insecure token handling and misconfiguration rather than Rails itself. JWTs are often adopted to move session management away from server-side storage, but they introduce new risks if not implemented carefully.

One common flaw is using weak or predictable signing algorithms. For example, a server may accept tokens signed with none or downgrade tokens from RS256 to HS256 by removing the public key portion and supplying a symmetric key. In Rails, if the application does not explicitly enforce algorithm validation when decoding, it may trust the header’s alg field, enabling an attacker to forge admin-level tokens.

Another vector is insufficient token binding and lack of revocation mechanisms. JWTs are often designed to be stateless and long-lived to reduce database lookups, but this increases the impact of token theft. In a Rails API consumed by mobile or single-page apps, if tokens do not include a per-user or per-session identifier (e.g., a jti claim), stolen tokens can be reused until expiry. Without a denylist or short expiry combined with secure refresh flows, compromised credentials remain valid across sessions.

Storage and transmission mistakes also contribute. If Rails controllers place JWTs into local storage on the client and do not enforce strict SameSite and Secure cookie attributes when using cookies, tokens become vulnerable to cross-site scripting (XSS) exfiltration. Similarly, failing to set the HttpOnly flag on cookies when storing tokens server-side can expose them to client-side scripts.

Middleware and library misconfigurations compound these issues. For instance, using an outdated jwt gem version may expose the application to known vulnerabilities, and skipping issuer and audience validation (verify_iss, verify_aud) allows tokens issued for another service or with mismatched audiences to be accepted. In Rails, these checks must be explicitly enforced in the token decoding logic, as defaults may be permissive.

Finally, insufficient entropy in signing keys and failure to rotate keys weakens the trust chain. Hardcoded secrets in version control or keys that never expire increase the likelihood of successful brute-force or credential reuse attacks. Together, these factors mean that even when JWTs are used, the authentication layer in Rails can remain vulnerable if each token lifecycle step is not rigorously protected.

To remediate broken authentication with JWTs in Rails, enforce strict algorithm validation, short expirations, secure storage, and explicit verification of claims. Below are concrete, secure code examples.

1. Enforce algorithm validation and issuer/audience checks

Always specify the expected algorithm and validate standard claims. Avoid passing the algorithm from the token header.

require 'jwt'

class JsonWebToken
  ALG = 'RS256'

  def self.decode(token, public_key)
    # Do not read alg from token; explicitly set it
    JWT.decode(
      token,
      public_key,
      true,
      {
        algorithm: ALG,
        iss: 'https://api.yourdomain.com',
        verify_iss: true,
        aud: 'your-api-audience',
        verify_aud: true,
        verify_expiration: true,
        verify_iat: true
      }
    )
  rescue JWT::ExpiredSignature
    raise 'Token expired'
  rescue JWT::VerificationError
    raise 'Invalid signature or claims'
  end
end

2. Use short access tokens and secure refresh flows

Keep access token lifetimes short (e.g., 15 minutes) and use HTTP-only, Secure, SameSite=Strict cookies for storage. Implement refresh tokens with strict rotation and revocation.

class SessionsController < ApplicationController
  def create
    user = User.find_by(email: params[:email])
    if user&;authenticate(params[:password])
      access_token = JsonWebToken.encode({ sub: user.id, scope: 'access' }, Rails.application.credentials.secret_key_base, 'HS256')
      refresh_token = SecureRandom.uuid

      # Store refresh token metadata server-side with user_id and revocation flag
      RefreshToken.create!(user: user, token: refresh_token, expires_at: 7.days.from_now)

      cookies.signed[:refresh_token] = {
        value: refresh_token,
        httponly: true,
        secure: Rails.env.production?,
        same_site: :strict,
        expires: 7.days.from_now
      }

      render json: { access_token: access_token, expires_in: 900 }
    else
      head :unauthorized
    end
  end
end

3. Add per-jti tracking and denylist for revocation

Include a unique JWT ID (jti) for each token and maintain a revocable record for logout or suspicious activity.

class JsonWebToken
  def self.encode(payload, secret, alg = 'HS256')
    payload[:jti] = SecureRandom.uuid
    payload[:exp] = 15.minutes.from_now.to_i
    JWT.encode(payload, secret, alg)
  end
end

class RevokedToken < ApplicationRecord
  # jti:string, exp:datetime, reason:string
  def self.revoked?(jti, exp)
    exists?(jti: jti) || exp < Time.current
  end
end

# In a before_action
jti = decoded_token['jti']
if RevokedToken.revoked?(jti, decoded_token['exp'])
  head :forbidden
end

4. Rotate keys and avoid algorithm confusion

Use distinct keys per environment, avoid none, and validate the presence of a kid only against a trusted key set.

module JwtAlgorithms
  def self.current_key
    # Use versioned key material and rotate periodically
    @current_key ||= Rails.application.credentials.jwks['keys'].first
  end
end

By combining strict decoding parameters, short-lived access tokens, server-side refresh token state, and explicit claim verification, Rails applications can mitigate the most common JWT-related authentication weaknesses.