OAuth integration basics in Ruby on Rails - Step-by-Step Execution

Concept Flow - OAuth integration basics

User clicks 'Login with Provider'

↓

Redirect to Provider's OAuth page

↓

User grants permission

↓

Provider redirects back with code

↓

App exchanges code for access token

↓

App uses token to get user info

↓

User logged in or registered

This flow shows how a user logs in using OAuth: starting from clicking login, granting permission, and the app getting user info to log them in.

Execution Sample

Ruby on Rails

# routes.rb: get '/auth/:provider/callback', to: 'auth#callback'
# app/controllers/auth_controller.rb
def callback
  auth = request.env['omniauth.auth']
  user = User.find_or_create_from_auth(auth)
  session[:user_id] = user.id
  redirect_to root_path
end

This code handles the OAuth callback in a Rails AuthController, finds or creates the user, saves their ID in session, and redirects home.

Execution Table

Step	Action	Data/Variable	Result/State Change
1	User clicks 'Login with Google'	N/A	Redirect to Google OAuth page
2	User grants permission	N/A	Google redirects back with code
3	App receives callback	request.env['omniauth.auth']	Auth hash with user info received
4	Find or create user	User.find_or_create_from_auth(auth)	User record found or created
5	Set session user_id	session[:user_id] = user.id	User logged in in session
6	Redirect to home	redirect_to root_path	User sees home page logged in

💡 OAuth flow completes after user is logged in and redirected home

Variable Tracker

Variable	Start	After Step 3	After Step 4	After Step 5	Final
auth	nil	{provider: 'google', uid: '123', info: {...}}	{provider: 'google', uid: '123', info: {...}}	{provider: 'google', uid: '123', info: {...}}	{provider: 'google', uid: '123', info: {...}}
user	nil	nil	User(id=1, name='Alice')	User(id=1, name='Alice')	User(id=1, name='Alice')
session[:user_id]	nil	nil	nil	1	1

Key Moments - 3 Insights

Why do we need to exchange the code for an access token?

The code is temporary and can't access user info directly. Exchanging it for a token lets the app securely get user data, as shown in step 4 of the execution_table.

What happens if the user is new and not in our database?

The method User.find_or_create_from_auth creates a new user record with the info from auth, so the app can log them in, as seen in step 4.

Why do we store user.id in session?

Storing user.id in session keeps the user logged in across requests, so the app knows who is logged in, as shown in step 5.

Visual Quiz - 3 Questions

Look at the execution_table, what variable holds the user info returned by the provider at step 3?

A session[:user_id]

B auth

C user

D request.env

💡 Hint

Check the 'Data/Variable' column at step 3 in execution_table

At which step does the app save the user ID in the session?

A Step 5

B Step 4

C Step 3

D Step 6

💡 Hint

Look at the 'Action' and 'Result/State Change' columns in execution_table

If the user denies permission on the provider page, what would happen in this flow?

A App receives auth hash and logs user in

B User is created anyway

C App never receives callback with code

D Session user_id is set to nil

💡 Hint

Think about step 2 and what happens if permission is not granted

Concept Snapshot

OAuth integration basics in Rails:
- User clicks login, redirected to provider
- Provider returns code after permission
- App exchanges code for access token
- App gets user info, finds or creates user
- User ID saved in session to keep login
- Redirect user to home page logged in

Full Transcript

This visual execution shows how OAuth integration works in a Rails app. The user starts by clicking a login button, which sends them to the provider's OAuth page. After granting permission, the provider redirects back with a code. The app receives this code in the callback route, exchanges it for an access token, and uses that token to get user info. Then the app finds or creates a user record and saves the user's ID in the session to keep them logged in. Finally, the user is redirected to the home page. Key points include exchanging the code for a token to securely get user data, creating a user if new, and storing user ID in session for login persistence.

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