joelbutcher / socialstream

OAuth for Laravel, simplified.

Home Page:https://docs.socialstream.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Logging in with a Socialite provider bypasses user's 2FA settings

Tesseeaye opened this issue · comments

Stack

Jetstream – Livewire

Package Version

6.0

Laravel Version

11.9

Livewire Version

3.0

react Version

No response

Vue Version

No response

PHP Version

8.3

Problem description

I'm working on a project that uses both Socialite and Jetstream to handle authentication. When a user has 2FA enabled and confirmed and they try to login with their username/password they get put through Fortify's auth process and will be presented with a 2FA challenge. If they login with any Socialite provider and they have 2FA enabled, the user will bypass the 2FA setting and be immediately logged in.

Expected behavior

Users should be confronted with the 2FA screen if it's enabled for them whether they sign in with their username/password or via Socialite.

Steps to reproduce

  1. Create a new Laravel project with Jetstream.
  2. Install Socialstream and run install command.
  3. Generate oAuth API key and add it to your .env.
  4. Add the provider to your services.php and enable it in Socialstreams configuration.
  5. Run migrations.
  6. Login/Register with oAuth provider and create your password.
  7. Enable 2FA and confirm it on your profile.
  8. Logout and log back in with your email and password, you'll get 2FA challenge screen, finish logging in.
  9. Log back out and log back in with your provider, you'll bypass the 2FA challenge screen and be at your dashboard.

I followed these instructions with the repository I linked. Let me know if there's more information I can provide to help!

Reproduction repository

https://github.com/Tesseeaye/socialstream-2fa-bug

Relevant log output

No response

commented

@joelbutcher just a heads up #361 doesn't respect when a user changes their email (email mismatch between users and connected_accounts)

@mystyq Thanks for this, though I think the issue was from a different PR (possibly #351)