When to use Laravel Passport even if you don’t need OAuth2

Passport and Sanctum are both packages that come with API authorization solutions.

At https://laravelpodcast.com/episodes in Season 5, Episode 5 “Sanctum & Passport” Taylor states, that the only use-case he knows for Passport is OAuth2, all other cases are covered by the much simpler package Sanctum. And he would love to know if there are other use cases, because Passport is the most popular package, and he does not understand why. This article tries to provide this example.

At the Passport documentation the following guidance for Passport or Sanctum is given:

Before getting started, you may wish to determine if your application would be better served by Laravel Passport or Laravel Sanctum. If your application absolutely needs to support OAuth2, then you should use Laravel Passport.

However, if you are attempting to authenticate a single-page application, mobile application, or issue API tokens, you should use Laravel Sanctum. Laravel Sanctum does not support OAuth2; however, it provides a much simpler API authentication development experience.

I would say the main difference is not OAuth2, but we will get into that.

Which problem does Sanctum solve?

Sanctum gives you an easy way to authenticate other applications and SPAs with your backend.

How to secure SPAs

For SPAs, they have to be in the same subdomain. As every request from any subdomain ships with the same cookie, authentication for API requests from SPA can be session based and does not require a token. If you need to catch up about sessions check out https://iwasherefirst2.medium.com/how-do-laravel-sessions-work-7b65d74a79a6.

If you have a Vue/React app that makes requests to your backend, it's recommended that it be at the same domain or any subdomain from your Laravel app. This allows to use Laravel built-in cookie-based session authentication, and benefits like using CSRF protection. So you just need to set up your domain, and maybe some CORS & Cookies settings. That’s it, no generation of tokens is required.

If you use something like Inertia.js it will come automatically with the configured session authentication.

How to secure applications

Sanctum offers you to simply create tokens for an Eloquent model. You also can set up abilities to your tokes to limit their access rights, and easily protect routes, and you have the option to set an expiration for your tokens.

Here are two basic use-cases when you want to have tokens:

Case A: Multiple Backend Services

Imagine you have two applications that communicate with each other

If you want to exchange secret information or allow to create resources, it is probably a good idea to protect the API endpoints using a token. Those tokens should not have an expiration date, as it's for your internal services communicating with each other.

Case B: Multiple User Tokens

Another scenario in which you may want tokens is to offer them to your users, so they can access your API. These tokens should have an expiration date, to protect your users if they are not careful with their tokens.

For both case A, and case B sanctum provides an easy solution. However, if you are in a scenario where you want to use both, expired tokens and permanent tokens. That is not possible for Sanctum.

This problem already appears when you have a mobile app and many users for that.

The mobile APP would use a login endpoint of your Laravel app to post username/email and receive a user token. Then the API is authorized with the users token to request all his personal data and show it on the mobile app. This example is given in the official docs at https://laravel.com/docs/9.x/sanctum#mobile-application-authentication

but it comes with a problem, the post route /sanctum/token where you send the username/email is not protected. Would it not be nice if the mobile app itself has a token for that endpoint, so it's the only application that can make requests against that endpoint? You can create two models with tokens, User and Client but Sanctum forces you to use the same expiration for both tokens. But the mobile app token should live forever, however, the token for the users should expire. This is why Sanctum is not the optimal solution for using it as a Mobile Application.

In short, that is my summary:

• Do not use Sanctum if you want to use OAuth2 (as it doesn’t support that protocol)
• Do use Sanctum if you want to use it for case A only, or case B only.
• Do not use Sanctum if you want to use it for a Mobile Application.
• Do not use Sanctum if you want to use it expiring and life-long tokens

So when to use Passport?

It's simple, just use Passport when you should not use Sanctum. Let's go over it:

Do use Passport if you want to use OAuth2

This is a no-brainer, as the sales pitch for Passport is that it supports the OAuth2 protocol.

Do not use Passport if you only need either expiring or life-long tokens

If you just want to use one type of token (either life-long or expirng) in your entire application without the need for OAuth2, there is no need to install Passport and migrate its 7 tables. You can use it, but it’s much more complicated to read and to set up. Just go with the clean and simple solution Sanctum provides.

Do use Passport for Mobile Applications or if you want to have expiring and life-long tokens in parallel.

But how could you do that with Passport without having to use OAuth2?

First, Passport comes with a Client’s table. Each client needs his own lifetime token. The token can be used for case A.

You can also issue personal access tokens directly without using OAuth2 as explained in https://laravel.com/docs/passport#passport-or-sanctum to cover case B.

So both cases A and B can be handled at the same time with Passport without the need to use OAuth2.

Summary

You should use Passport if you need OAuth2 or if you need to support expiring and life-long tokens at the same time. If you only need expiring tokens OR only need life-long tokens (or no tokens at all because you have a SPA), then use Sanctum.