Replies: 1 comment
-
|
Related to laravel/passport#1743 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
For context, I'm working on a hobby project which would offer multiple authentication schemes for API (which would include cookies, long-lived access token, jwt - refresh token combo,...) since the credentials check is the same and just what to return differs.
Basically I wanted feature parity for all the schemes, but I can't help but notice that some features, namely rehash password, and timebox to prevent side channel timing attacks, only exist in the
SessionGuard, which implement theStatefulGuardinterface.examining the
Auth::attempt()method:Authenticableobject is retrieved by the provider and set the the$lastAttemptedvariableAuthenticableobject in aTimeboxLoginandAuthenticatedevents,...)I can see that 3. and 4. doesn't exist on the
TokenGuard, or theRequestGuard, even though for the rehash password, the implementation actually comes from theUserProvider, and both features conceptually doesn't really need to be statefulThis had a couple of problems that I can see:
StatefulGuard(SessionGuard) and the regularGuard(TokenGuardandRequestGuard) beyond statefulness vs statelessnessTokenGuardis effectively non-existent in the docs (even the "supported driver" section inconfig/auth.php), if it is deprecated, it should be warned so in the docsRequestGuard, which is still in use and recommended in the docs, withAuth::viaRequest()will be unable to utilize these featuresBonus: I'm aware that all token based approaches is recommended to go through Sanctum or Passport, and Sanctum do use
SessionGuardunder the hood. And there exists theAuth::once()method to do stateless auth with thesessiondriver. But:User::where()andHash::check(), at the very least, it should mention the use ofTimeboxto Guard against timing attack or should rehash the password on login. Or they should just recommendAuth::once()Timebox, there is no documentation on it, either how to interact with or what to do with it.Auth::once(), it is not currently emit theIlluminate\Auth\Events\Failedevent (viafireFailedEvent()) as oppose toAuth::attempt(), orAuth::attemptWhen(). Unsure if this is oversight or there is deeper reason I am unaware of.Auth::attemptWhen(), there is noAuth::onceWhen()equivalent ofAuth::once()Auth::attempt()andAuth::attemptWhen(), you can just callAuth::attemptWhen()insideAuth::attempt()withcallback: nullGuardshad theMacroabletrait, the docs had no information on how to use them, currently i am just extending theSessionGuardand register it as a new custom guardI am open to contribute some PRs myself, but I want to see if any of the points I raise had some deeper reasons that I am not aware of.
To summary, there is some potential improvement:
TokenGuardas deprecated (?)Auth::once()Auth::onceWhen()methodTimeBoxBeta Was this translation helpful? Give feedback.
All reactions