OAuth integration basics in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens after successful OAuth callback in Rails?

In a Rails app using OAuth, after the user authorizes the app and the OAuth provider redirects back, what is the typical next step in the controller handling the callback?

A The app sends an email to the user asking to confirm the OAuth authorization.

B The app immediately redirects the user to the OAuth provider's homepage.

C The app deletes the user session and logs the user out.

D The app exchanges the received code for an access token and creates or updates the user session.

💡 Hint

Think about what the app needs to do to get permission to act on the user's behalf.

After OAuth provider redirects back with a code, the app must exchange it for an access token to authenticate the user and create or update the session.

📝 Syntax

intermediate

Identify the correct OmniAuth middleware setup in Rails

Which of the following is the correct way to configure OmniAuth middleware for GitHub OAuth in a Rails app's config/initializers/omniauth.rb?

A

Rails.middleware.use OmniAuth::Builder do
  provider :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET']
end

B

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET']
end

C

Rails.application.config.middleware.add OmniAuth::Builder do
  provider :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET']
end

D

Rails.application.middleware.use OmniAuth::Builder do
  provider :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET']
end

💡 Hint

Check the exact method to add middleware in Rails application config.

The correct syntax uses Rails.application.config.middleware.use to add OmniAuth::Builder with the provider block.

🔧 Debug

advanced

Why does the OAuth callback fail with 'invalid redirect_uri' error?

A Rails app using OAuth gets an 'invalid redirect_uri' error from the provider during callback. What is the most likely cause?

A The redirect_uri sent in the OAuth request does not exactly match the one registered in the OAuth provider settings.

B The OAuth client ID is missing from the request parameters.

C The user denied the OAuth authorization request.

D The Rails app is missing the CSRF token in the callback request.

💡 Hint

OAuth providers require exact URL matches for security.

OAuth providers check that the redirect_uri in the request matches exactly what was registered to prevent malicious redirects.

❓ state_output

advanced

What is stored in session after OAuth login?

After a successful OAuth login in a Rails app, which of the following is the most common data stored in the session?

A The user's OAuth access token and refresh token in plain text.

B The entire OAuth response hash including sensitive tokens.

C The user's unique ID or user record ID to identify the logged-in user.

D The user's password in encrypted form.

💡 Hint

Think about what minimal info is needed to keep the user logged in securely.

Storing only the user ID in session is secure and sufficient to identify the user; tokens are usually stored encrypted in the database if needed.

🧠 Conceptual

expert

Why use OAuth scopes in integration?

In OAuth integration, why do apps request specific scopes during authorization?

A To limit the app's access to only the permissions it needs, enhancing user trust and security.

B To speed up the OAuth authorization process by skipping user consent.

C To allow the app to access all user data without restrictions.

D To automatically refresh the access token without user interaction.

💡 Hint

Think about why apps ask for permission to access only some data, not everything.

Scopes define what data or actions the app can access, helping users control their privacy and limiting app permissions.

Practice

1. What is the main purpose of using OAuth in a Rails application?

easy

A. Encrypt user passwords stored in the database

B. Allow users to log in using credentials from other services without sharing passwords

C. Automatically generate user passwords

D. Manage database migrations securely

Solution

1. Step 1: Understand OAuth's role

   OAuth allows users to authenticate using external services like Google or Facebook without sharing their passwords with your app.

2. Step 2: Identify the correct purpose in Rails context

   In Rails, OAuth integration is mainly for user login via third-party providers, not for password encryption or database tasks.

3. Final Answer:

   Allow users to log in using credentials from other services without sharing passwords -> Option B

4. Quick Check:

   OAuth = External login without password sharing [OK]

Hint: OAuth = login via other services, no password sharing [OK]

Common Mistakes:

• Confusing OAuth with password encryption
• Thinking OAuth generates passwords
• Assuming OAuth manages database migrations

2. Which of the following is the correct way to add OmniAuth middleware for GitHub in a Rails app's config/initializers/omniauth.rb file?

easy

A. OmniAuth.configure do |config|
config.provider :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET']
end

B. Rails.middleware.add OmniAuth::GitHub, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET']

C. Rails.application.middleware.insert OmniAuth::Builder, :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET']

D. Rails.application.config.middleware.use OmniAuth::Builder do
provider :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET']
end

Solution

1. Step 1: Recall OmniAuth middleware setup syntax

   The standard way is to use Rails.application.config.middleware.use OmniAuth::Builder with a block specifying providers.

2. Step 2: Match the correct syntax for GitHub provider

   The block should call provider :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET'] inside the middleware use call.

3. Final Answer:

   Rails.application.config.middleware.use OmniAuth::Builder do provider :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET'] end -> Option D

4. Quick Check:

   Middleware use with provider block = Rails.application.config.middleware.use OmniAuth::Builder do provider :github, ENV['GITHUB_KEY'], ENV['GITHUB_SECRET'] end [OK]

Hint: Use middleware.use with a block for providers [OK]

Common Mistakes:

• Using incorrect middleware methods like add or insert
• Misplacing provider call outside the block
• Wrong OmniAuth configuration syntax

3. Given this simplified controller code handling OAuth callback, what will session[:user_id] be set to if the user is found?

def github
  auth = request.env['omniauth.auth']
  user = User.find_by(uid: auth['uid'], provider: auth['provider'])
  if user
    session[:user_id] = user.id
    redirect_to root_path
  else
    redirect_to login_path
  end
end

medium

A. The user's database ID

B. The OAuth provider name

C. The user's email address

D. Nil, because session is not set

Solution

1. Step 1: Analyze user lookup and session assignment

   The code finds a user by UID and provider from OAuth data. If found, it sets session[:user_id] to user.id.

2. Step 2: Understand what user.id represents

   This is the user's unique database ID, used to track logged-in users in the session.

3. Final Answer:

   The user's database ID -> Option A

4. Quick Check:

   session[:user_id] = user.id means database ID [OK]

Hint: Session user_id stores database user ID after login [OK]

Common Mistakes:

• Confusing session user_id with provider or email
• Assuming session is not set
• Misreading user lookup logic

4. Identify the error in this OAuth callback method:

def google
  auth = request.env['omniauth.auth']
  user = User.find_or_create_by(uid: auth['uid']) do |u|
    u.email = auth['info']['email']
    u.provider = auth['provider']
  end
  session[:user_id] = user.id
  redirect_to root_path
end

medium

A. Missing provider in find_or_create_by conditions causes duplicate users

B. Using find_or_create_by with a block is invalid syntax

C. Accessing auth['info']['email'] should be auth['email']

D. Session assignment should happen before user creation

Solution

1. Step 1: Check find_or_create_by conditions

   The method only uses uid: auth['uid'] to find or create a user, missing provider in the lookup.

2. Step 2: Understand impact of missing provider

   Without provider, users with same UID from different providers may be treated as the same user, causing duplicates or wrong matches.

3. Final Answer:

   Missing provider in find_or_create_by conditions causes duplicate users -> Option A

4. Quick Check:

   Include provider in find_or_create_by to avoid duplicates [OK]

Hint: Always include provider with uid in find_or_create_by [OK]

Common Mistakes:

• Thinking block with find_or_create_by is invalid
• Misreading auth hash structure
• Assuming session order causes error

5. You want to support login via multiple OAuth providers (Google, GitHub) in your Rails app. Which approach correctly handles user creation to avoid duplicate accounts when the same email is used across providers?

def oauth_callback
  auth = request.env['omniauth.auth']
  user = User.find_by(email: auth['info']['email'])
  if user
    # What should happen here?
  else
    user = User.create(
      email: auth['info']['email'],
      uid: auth['uid'],
      provider: auth['provider']
    )
  end
  session[:user_id] = user.id
  redirect_to root_path
end

hard

A. Ignore provider and uid, just use email for login

B. Create a new user regardless, to keep providers separate

C. Update user's uid and provider if missing, to link accounts

D. Raise an error if email exists to prevent duplicates

Solution

1. Step 1: Understand the problem of duplicate accounts

   Users may log in with different providers but same email. Creating new users each time causes duplicates.

2. Step 2: Best practice is to link accounts

   If a user with the email exists, update their uid and provider fields if missing to link OAuth data to one account.

3. Final Answer:

   Update user's uid and provider if missing, to link accounts -> Option C

4. Quick Check:

   Link accounts by updating uid/provider on existing email [OK]

Hint: Link accounts by updating uid/provider on existing email [OK]

Common Mistakes:

• Creating new users for each provider causing duplicates
• Ignoring provider and uid fields
• Raising errors instead of linking accounts