Accounts & Access Control
Laravel resolves the caller through guards, signs users in and resets passwords, then decides what they may do with gates and policies. Interviewers probe it because the two halves get conflated.
on this pageshowhide
explore
- Sanctum6 questions
- Passport OAuth Server6 questions
- Gates & Policies6 questions
- Guards & User Providers5 questions
- Fortify Auth Backend6 questions
- Manual Sign-In & Logout6 questions
- Password Reset & Verification6 questions
- Socialite Social Login6 questions
questions
page 2 of 2How does Laravel Fortify throttle login attempts, and what changes when config/fortify.php sets limiters.login to a named rate limiter?
basics
~20 sWith limiters.login empty, Fortify's own EnsureLoginIsNotThrottled step allows 5 failed attempts per username-and-IP key before a 429. With limiters.login set to a name, as in the stub, the login route gets throttle:login instead, using the RateLimiter::for('login') definition in FortifyServiceProvider.
In Laravel, how do Response::deny, denyWithStatus, denyAsNotFound and Gate::inspect change what a denied authorization check tells the caller?
basics
~10 sA policy can return Illuminate\Auth\Access\Response: deny('message') keeps 403 with a custom message, denyWithStatus() picks another status, denyAsNotFound() returns 404 to hide existence. Gate::inspect() returns that Response without throwing, for reading the message.
In Laravel, how does Auth::logoutOtherDevices() sign a user out elsewhere, and why does it depend on the auth.session middleware?
basics
~20 sAuth::logoutOtherDevices($password) checks the current password and re-hashes it, changing the stored hash. The auth.session middleware (AuthenticateSession) compares each session's saved password-hash marker with the user's current hash, so other sessions stop matching and are logged out on their next request.
A carrier's nightly sync calls a Laravel Passport route with a client-credentials token and gets 401 from auth:api — why, and what should protect that route instead?
basics
~10 sA client-credentials token has no user, so Passport's TokenGuard resolves no user and auth:api answers 401. Protect machine routes with EnsureClientIsResourceOwner (optionally ::using(scopes)), which validates the token itself and accepts only client-owned tokens.
When a Laravel Passport API runs on several servers behind a load balancer, where must the signing keys come from, and what breaks if each server runs passport:keys?
basics
~20 sEvery server must share one key pair, injected through PASSPORT_PRIVATE_KEY and PASSPORT_PUBLIC_KEY or a shared path set with Passport::loadKeysFrom(). If each server runs passport:keys, tokens signed on one server fail verification on another, so requests randomly get 401.
Laravel Passport access tokens last a year by default — how do tokensExpireIn and its siblings work, why is expires_at display-only, and what does passport:purge remove?
basics
~10 sPassport::tokensExpireIn(), refreshTokensExpireIn() and personalAccessTokensExpireIn() each default to one year; clientCredentialsTokensExpireIn() falls back to tokensExpireIn. Expiry is baked into the signed token, so expires_at is display-only; revoke to invalidate. passport:purge deletes revoked and long-expired rows.
A Laravel forgot-password endpoint copied from the documented example reveals which email addresses have accounts - where does it leak, and how do you close it?
basics
~20 sThe broker returns passwords.user for unknown emails but passwords.sent or passwords.throttled for real ones, and the handler shows different messages. Show one neutral message, move slow mail sending out of the request so the 200 ms timebox can hide it, and rate-limit the route.
In Laravel, what does EmailVerificationRequest check when a user opens the verification link, and what must happen when a verified user changes their email address?
basics
~20 sEmailVerificationRequest authorizes only if the route's id equals the signed-in user's key and its hash equals sha1 of that user's current email; fulfill() then sets email_verified_at and fires Verified. On an email change, call markEmailAsUnverified() and resend the link.
With Laravel Sanctum, how do the abilities and ability middleware differ, and why does a first-party SPA request pass every token ability check?
basics
~20 sabilities (CheckAbilities) requires every listed ability; ability (CheckForAnyAbility) requires one. A session-authenticated SPA user gets a TransientToken whose can() always returns true, so ability checks pass and real permission must come from a policy or gate.
Laravel Sanctum tokens never expire by default — how do the expiration config key, createToken's expiresAt argument and sanctum:prune-expired work together?
basics
~20 sconfig('sanctum.expiration') defaults to null, so tokens never expire. When set, it counts minutes from created_at; createToken's third argument sets expires_at. A token failing either check is rejected. sanctum:prune-expired deletes long-expired rows, but only if you schedule it.
On a Laravel site with GitHub and Google sign-in, why is linking the Socialite user to a local account by email alone dangerous, and what should the callback do instead?
basics
~20 sEmail-only matching lets anyone who controls an address at a provider, or pre-registered it locally unverified, take over the account. Key links on provider plus getId(); merge by email only when both sides are verified.
A mobile app sends your Laravel API a Google token for Socialite's userFromToken(); what does Socialite check about that token, and what does it leave to you?
basics
~20 suserFromToken() fetches the profile for a token the client already holds. For a Google ID token, Socialite verifies signature, issuer and audience; an opaque access token just goes to userinfo, with no check of which app it was issued to.
In Laravel Fortify, what does Fortify::authenticateUsing replace in the login pipeline, and what must its callback take care of?
basics
~20 sFortify::authenticateUsing replaces the credential check: instead of guard->attempt(), Fortify calls your closure, which must verify the credentials and return the user or null/false; Fortify then calls login() on the guard. Throttling, two-factor and session regeneration still run around it.
In Laravel Passport 13, what kind of client does each passport:client flag create, and why does a --password client fail until enablePasswordGrant() is called?
basics
~20 sNo flag creates an authorization-code client; --client a client-credentials client, --device a device-flow client, --personal the personal access client, --password and --implicit legacy clients, --public one without a secret. The password grant itself is only registered after Passport::enablePasswordGrant().
With Laravel Socialite, which provider tokens does the callback return, and how do you keep calling the provider's API after expiry?
basics
~10 sThe Socialite user carries token, refreshToken, expiresIn and approvedScopes. Store them encrypted if you need provider API access, and when the access token expires call Socialite::driver(...)->refreshToken($refresh), which returns a Laravel\Socialite\Two\Token with fresh values.
How do you enable passkeys with Laravel Fortify 1.40, and what does the application still have to provide itself?
basics
~10 sAdd Features::passkeys() to config/fortify.php, make User implement Laravel\Fortify\Contracts\PasskeyUser and use PasskeyAuthenticatable, run the migrations, and set relying_party_id and allowed_origins. The app still provides the screens and the browser WebAuthn calls, usually through @laravel/passkeys.
In Laravel, when would you register a custom guard with Auth::viaRequest rather than Auth::extend, and where does Auth::provider fit?
basics
~20 sAuth::viaRequest wraps a closure that takes the request and returns a user or null in a stateless RequestGuard; Auth::extend registers a factory for your own Guard class. Auth::provider is different: it adds a user-storage driver, not a new way to authenticate.
showing 31–47 of 47