#API Refresh tokens, implement manually (Sanctum) or over-engineer (Passport)?

7 messages · Page 1 of 1 (latest)

civic valley
#

We're developing an API to serve as the backend for a mobile app.

While deciding how to handle authentication, we're deciding between using Sanctum or Passport and I would like to gather some more opinions if possible (Thanks in advance for anyone helping!)

Our mobile app needs to be able to maintain access the whole time as long as the user does not logs out. But API tokens never expiring seems insecure, so we want our tokens to have an expiry date and give the app an endpoint to refresh it's token.

Sanctum doesn't have refresh_tokens natively, so naturally we looked to Passport.

But Passport seems over-engineering this, it doesn't make sense for us to have to generate a client_id and client_secret for our own mobile app be able to log in. Plus, the fact the that Password Grant clients are created via an artisan command feels like it's going to be a problem for CI/CD.

We're thinking about using Sanctum and implement a refresh_token feature manually, but before taking this decision, I wanted to gather some info on the community about the best approach to this situation, maybe a package I didn't know yet already solves our problem?

gentle isle
civic valley
# gentle isle Sanctum does support token expiration: <https://laravel.com/docs/12.x/sanctum#to...

That's my point. While it does have token expiration it does not have the refresh logic, so on the mobile app side, that would make the user be prompted to login again once the token expires.

That's exactly what we want to avoid.

Just wondering if it's best to implement manually the refresh logic on sactum, handle the overhead of using Passport even though it seems over-enginereed for our case

idle vortex
#

What exactly is the purpose you're trying to achieve with refresh tokens? I'm not an expert, but AFAIK the use case for refresh tokens is when you have a separate auth server (which issues access tokens) and resource servers which consume them. If you have a single API server that's also the auth "authority" I don't see what you'd gain.

Edit: my point is that you always have the option to revoke a token, regardless of its lifetime.

civic valley
# idle vortex What exactly is the purpose you're trying to achieve with refresh tokens? I'm no...

The idea is that an API token is something quite dangerous to be leaked. Obviously we're taking precautions to not leak the API token stored on the mobile app. But regardless, if eventually a token ends up leaking. Having an expiration time reduces the chances of that leaked token having enough time to do any serious damage to the system.

But simply expiring the token would force the mobile user to log-in again, and that's exatclty what we're trying avoid here.

By having a refresh_token, the mobile app could automically refresh the expired access_token

stray elk
# civic valley The idea is that an API token is something quite dangerous to be leaked. Obvious...

Some say refresh token not increasing anything in security. Because if your access token got stolen, there is also a chance refresh token will get stolen too if you frequently call the API.

From my understanding, refresh token is just for usability and decrease the user auth step.
Lets say you have a document in server and want to download it

  1. You login into oauth to get the token.
  2. Using the token you call a http request to download the doc
  3. Youre done and not call the api for a while
  4. After 30-60 minutes, suddenly you want download the file again but the token is expired
  5. Without using login again, you just use refresh token to get a new token and download the file.

So if your mobile app using the API as main resource (Frequently call the api), sanctum is the best choice.
CMIIW

civic valley