Token-based authentication in Ruby on Rails - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is token-based authentication in Rails?

Token-based authentication is a way to verify a user's identity by issuing a unique token after login. This token is sent with each request to prove the user is authorized, without needing to send username and password every time.

beginner

How does Rails typically store tokens for API authentication?

Rails often stores tokens in the database linked to the user, usually in a column like authentication_token. This token is sent in request headers to authenticate API calls.

intermediate

Why is token-based authentication better than session-based for APIs?

Token-based authentication is stateless, meaning the server does not keep session info. This makes it easier to scale APIs and allows clients like mobile apps to authenticate without cookies.

beginner

What HTTP header is commonly used to send the token in Rails API requests?

The Authorization header is commonly used, often with the format Bearer <token> to send the token securely with each request.

beginner

How can you generate a secure token in Rails?

You can use SecureRandom.hex(20) or has_secure_token in Rails models to generate a random, secure token string for authentication.

Which of these is a key benefit of token-based authentication in Rails APIs?

A It only works with web browsers

B It requires cookies to work

C It is stateless and scales well

D It stores passwords in tokens

Token-based authentication is stateless, meaning the server does not store session info, making it easier to scale APIs.

Where is the authentication token usually sent in an API request?

A In the Authorization HTTP header

B In the URL query string

C In the request body only

D In a cookie named 'token'

Tokens are commonly sent in the Authorization header, often as 'Bearer '.

Which Rails method helps generate a secure random token?

A SecureRandom.hex

B rand()

C to_s

D digest()

SecureRandom.hex generates a secure random hexadecimal string suitable for tokens.

What does 'stateless' mean in token-based authentication?

A Client must send username and password every time

B Server stores user sessions in memory

C Tokens expire immediately

D Server does not keep session info

Stateless means the server does not keep session info; the token itself carries the authentication data.

Which of these is NOT a good practice for token-based authentication?

A Storing tokens securely in the database

B Sending tokens in plain HTTP

C Sending tokens over HTTPS

D Using long random tokens

Tokens should never be sent over plain HTTP because it risks interception.

Explain how token-based authentication works in a Rails API.

Think about the steps from login to making authenticated API calls.

Describe why token-based authentication is preferred over session-based authentication for APIs.

Consider how servers handle user state and how clients communicate.

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