Token-based authentication in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What does this Rails controller action return when a valid token is provided?

Consider this Rails API controller action that uses token-based authentication. What will be the JSON response if the token is valid?

Ruby on Rails

class Api::V1::ProfilesController < ApplicationController
  before_action :authenticate_user!

  def show
    render json: { email: current_user.email, name: current_user.name }
  end

  private

  def authenticate_user!
    token = request.headers['Authorization']&.split(' ')&.last
    user = User.find_by(authentication_token: token)
    if user
      @current_user = user
    else
      render json: { error: 'Unauthorized' }, status: :unauthorized
    end
  end

  def current_user
    @current_user
  end
end

A 500 Internal Server Error

B {"email": null, "name": null}

C {"email": "[e-mail]", "name": "Alice"}

D {"error": "Unauthorized"}

💡 Hint

Think about what happens when the token matches a user in the database.

If the token matches a user, the authenticate_user! method sets @current_user. Then the show action returns the user's email and name as JSON.

📝 Syntax

intermediate

Which option correctly defines a method to generate a secure token in a Rails model?

You want to add a method in your Rails User model that generates a unique authentication token. Which code snippet is syntactically correct and secure?

Ruby on Rails

class User < ApplicationRecord
  before_create :generate_authentication_token

  private

  def generate_authentication_token
    # Which option is correct here?
  end
end

A self.authentication_token = SecureRandom.hex(20)

B authentication_token = SecureRandom.hex(20)

C self.authentication_token = SecureRandom.random_number(20)

D authentication_token = SecureRandom.base64(20)

💡 Hint

Remember to assign to the attribute with self. inside instance methods.

Inside instance methods, to set an attribute you must use self.attribute = value. SecureRandom.hex(20) generates a secure 40-character hex string. Other options either miss self. or use incorrect methods.

❓ state_output

advanced

What is the value of current_user after this request with an invalid token?

Given this controller snippet, what will current_user be if the token is invalid?

Ruby on Rails

class Api::V1::SessionsController < ApplicationController
  before_action :authenticate_user!

  def index
    render json: { user: current_user&.email }
  end

  private

  def authenticate_user!
    token = request.headers['Authorization']&.split(' ')&.last
    user = User.find_by(authentication_token: token)
    if user
      @current_user = user
    else
      render json: { error: 'Unauthorized' }, status: :unauthorized
    end
  end

  def current_user
    @current_user
  end
end

A User object with email "[e-mail]"

B nil

C Raises NoMethodError

D "" (empty string)

💡 Hint

What happens if the token does not match any user?

If the token is invalid, @current_user is never set, so current_user returns nil.

🔧 Debug

advanced

Why does this token authentication code always return 'Unauthorized' even with a valid token?

Examine this code snippet. It should authenticate users by token but always returns 'Unauthorized'. What is the bug?

Ruby on Rails

def authenticate_user!
  token = request.headers['Authorization']&.split(' ')&.last
  user = User.find_by(authentication_token: token)
  if user.nil?
    render json: { error: 'Unauthorized' }, status: :unauthorized
  else
    @current_user = user
  end
end

A The token is not stripped of whitespace before lookup, causing find_by to fail

B The method returns before setting @current_user because render does not halt execution

C The condition should check if user is present, not nil

D The token variable is nil because the header key is case-sensitive and should be 'authorization'

💡 Hint

Check how the token string is extracted and used.

If the token string includes extra spaces or newline characters, find_by will not find the user. Stripping whitespace from the token fixes this.

🧠 Conceptual

expert

Which statement best explains the security benefit of token-based authentication over session-based authentication in Rails APIs?

Choose the most accurate explanation of why token-based authentication is preferred for APIs compared to traditional session-based authentication.

A Sessions require HTTPS, but tokens can be safely sent over HTTP without encryption.

B Tokens automatically expire after 5 minutes, making them more secure than sessions which never expire.

C Token-based authentication requires cookies, which are more secure than headers used in session authentication.

D Tokens are stored on the client and sent with each request, avoiding server-side session storage and enabling stateless APIs.

💡 Hint

Think about how APIs handle user state and scalability.

Token-based authentication stores tokens on the client and sends them with each request, so the server does not need to keep session state. This makes APIs stateless and easier to scale. Other options are incorrect or insecure.

Practice

1. What is the main purpose of token-based authentication in Rails?

easy

A. To identify users securely without requiring passwords every time

B. To store user passwords in plain text

C. To create server sessions for each user

D. To encrypt database records automatically

Solution

1. Step 1: Understand token-based authentication

   Token-based authentication uses a secret token to identify users securely without needing passwords repeatedly.

2. Step 2: Compare options

   Only To identify users securely without requiring passwords every time correctly describes this purpose; others describe unrelated or incorrect behaviors.

3. Final Answer:

   To identify users securely without requiring passwords every time -> Option A

4. Quick Check:

   Token-based authentication = Identify users securely without passwords [OK]

Hint: Tokens replace passwords for repeated user identification [OK]

Common Mistakes:

• Confusing tokens with password storage
• Thinking tokens create server sessions
• Assuming tokens encrypt data automatically

2. Which Rails method adds a secure token to a model for token-based authentication?

easy

A. has_secure_password

B. validates_token

C. has_secure_token

D. generate_token

Solution

1. Step 1: Recall Rails token helper methods

   Rails provides has_secure_token to add a secure token to models easily.

2. Step 2: Eliminate incorrect options

   has_secure_password is for passwords, not tokens; others are not valid Rails methods.

3. Final Answer:

   has_secure_token -> Option C

4. Quick Check:

   Token method in Rails = has_secure_token [OK]

Hint: Remember: token method is 'has_secure_token' not 'password' [OK]

Common Mistakes:

• Confusing has_secure_token with has_secure_password
• Using non-existent methods like generate_token
• Assuming validates_token is built-in

3. Given the model code:

class User < ApplicationRecord
  has_secure_token :auth_token
end

user = User.new
user.save
puts user.auth_token.nil?

What will be the output?

medium

A. false

B. Error: undefined method

C. nil

D. true

Solution

1. Step 1: Understand has_secure_token behavior

   When a new User is saved, Rails automatically generates a unique token for auth_token, so it won't be nil.

2. Step 2: Evaluate the output of puts user.auth_token.nil?

   Since auth_token is set, nil? returns false, so output is false.

3. Final Answer:

   false -> Option A

4. Quick Check:

   Token generated on save = false for nil? [OK]

Hint: Tokens auto-generate on save, so nil? returns false [OK]

Common Mistakes:

• Assuming token is nil before save
• Expecting nil output instead of false
• Confusing method names causing errors

4. Identify the error in this token authentication setup:

class ApiUser < ApplicationRecord
  has_secure_token :auth_token
end

user = ApiUser.new
user.auth_token = nil
user.save
puts user.auth_token.nil?

medium

A. user.save will raise an exception due to nil token

B. has_secure_token requires a token column named 'token', not 'auth_token'

C. Token is not generated because auth_token was manually set to nil before save

D. No error; output will be false

Solution

1. Step 1: Recall has_secure_token generation condition

   has_secure_token :auth_token generates a token if auth_token.blank? before save (nil.blank? returns true).

2. Step 2: Trace code execution

   Setting user.auth_token = nil keeps it blank, so save generates the token. user.auth_token.nil? returns false. No error.

3. Final Answer:

   No error; output will be false -> Option D

4. Quick Check:

   nil.blank? = true -> generates token [OK]

Hint: Setting to nil does NOT prevent generation; nil.blank? = true [OK]

Common Mistakes:

• Thinking setting to nil prevents token generation
• Expecting save to raise error on nil token
• Thinking output is true because manually set to nil

5. You want to secure an API in Rails using token-based authentication. Which approach correctly checks the token sent in request headers against the stored user token?

hard

A. Store tokens in cookies and check them with session[:token]

B. Use before_action to find user by auth_token from request.headers['Authorization'] and reject if not found

C. Use has_secure_password to verify token in params

D. Generate a new token on every request and compare with stored token

Solution

1. Step 1: Understand token authentication in APIs

   APIs commonly send tokens in headers; Rails can check request.headers['Authorization'] to find the user.

2. Step 2: Evaluate options for correctness

   Use before_action to find user by auth_token from request.headers['Authorization'] and reject if not found correctly uses before_action to authenticate by token. Options B and C misuse cookies and password helpers. Generate a new token on every request and compare with stored token is insecure and impractical.

3. Final Answer:

   Use before_action to find user by auth_token from request.headers['Authorization'] and reject if not found -> Option B

4. Quick Check:

   API token check = before_action with header token [OK]

Hint: Check token in headers with before_action for API security [OK]

Common Mistakes:

• Using cookies or sessions for API token storage
• Confusing password helpers with token verification
• Generating new token each request causing mismatch