[13.x] Deprecate JSON API

[hafezdivandari]

This PR fixes a few bugs in the current implementation of JSON API and deprecates it because:

• It falls outside the core purpose of Passport as an OAuth2 server implementation.
• Similarly, Sanctum doesn't offer a JSON API for managing PATs, and not every app needs third-party client registration.
• It adds 10 web routes, 4 controllers, mostly not reusable, not customizable and too opinionated; Makes Passport feature bloated without adding much value.
• We're already asking developers to create their own UI to use this API. Building the backend for this is a straightforward CRUD operation, which is simpler for developers to implement / customize on their side than feature bloating Passport.
• Doesn't comply RFC specifications unlike rest of the code.

Deprecations

• \Laravel\Passport\Http\Controllers\AuthorizedAccessTokenController controller class.
• \Laravel\Passport\Http\Controllers\ClientController controller class.
• \Laravel\Passport\Http\Controllers\PersonalAccessTokenController controller class.
• \Laravel\Passport\Http\Controllers\ScopeController controller class
• \Laravel\Passport\Http\Rules\RedirectRule rule class.
• \Laravel\Passport\Http\Rules\UriRule rule class.
• \Laravel\Passport\TokenRepository repository class and its findForUser and forUser methods.
• \Laravel\Passport\ClientRepository::findForUser, forUser, update, and delete repository methods.

Removal

• \Laravel\Passport\RefreshTokenRepository repository class has been removed as it was a duplicate of \Laravel\Passport\Bridge\RefreshTokenRepository class.
• \Laravel\Passport\TokenRepository::isAccessTokenRevoked and revokeAccessToken, create, find, getValidToken, save, and findValidToken repository methods have been removed as they were duplicated on \Laravel\Passport\Bridge\AccessTokenRepository class or weren't used.
• \Laravel\Passport\ClientRepository::activeForUser and revoked methods have been removed as they weren't used.

Changes

• Adds Passport::$registersJsonApiRoutes = false.
• Doesn't register JSON API routes by default anymore.

Upgrade Guide

You may call Passport::$registersJsonApiRoutes = true if you want to continue using deprecated JSON API.

[github-actions]

Thanks for submitting a PR!

Note that draft PR's are not reviewed. If you would like a review, please mark your pull request as ready for review in the GitHub user interface.

Pull requests that are abandoned in draft may be closed due to inactivity.

[hafezdivandari]

Hi @driesvints would you please merge 12.x into 13.x? thanks.

[taylorotwell]

Can we really fully remove this API? If there are bugs we could just fix them? Not every Laravel application will be using Jetstream... how will those people use Passport?

[driesvints]

@hafezdivandari done

[hafezdivandari]

Can we really fully remove this API? If there are bugs we could just fix them?

@taylorotwell This API falls outside the core purpose of Passport as an OAuth2 server implementation, which is why we can confidently remove it. Passport doesn't rely on this API for its primary functions, making it unnecessary.

Similarly, Sanctum doesn't offer a JSON API for managing PATs - we use Sanctum for issuing tokens and Jetstream for managing them.

Not every Laravel application will be using Jetstream... how will those people use Passport?

Not every app needs third-party client registration. We're deprecating this feature in favor of a more modern, opt-in alternative —the Jetstream OAuth feature— where this functionality naturally fits.

Moreover, we're already asking developers to create their own UI to use this API. Building the backend for this is a straightforward CRUD operation, which is simpler for developers to implement on their side (even by copy / pasting deprecated controllers) than feature bloating Passport.

[taylorotwell]

We are redoing our starter kits so we shouldn't recommend Jetstream / Breeze for this UI.

[hafezdivandari]

@taylorotwell This PR is still applicable, as we are not recommending any UI on this PR, just deprecating the JSON API as we don't have any UI for it and it's falls outside the core purpose of Passport as I explained earlier.

but about redoing the starter kits, sorry I'm confused. You mean is there going to be a new starter kit to integrate Passport into? or the following 2 PRs on Jetstream / Breeze is going to be a waste of time even after this confirmation?

• [5.x] Support Laravel Passport jetstream#1521
• [2.x] Support Laravel Passport breeze#398

cc @driesvints

[taylorotwell]

@hafezdivandari I think we would just want to repurpose that work towards our new starter kit work we take on this fall. 👍

[hafezdivandari]

@taylorotwell the bugs I mentioned earlier are now fixed and the upgrade guide is updated.

[hettiger]

Jetstream and the new starter kits are very opinionated. I would not make the assumption of anyone using these when making such decisions. I've been using Passport since v7 in my app. Changes like these are very annoying and I think @taylorotwell had a very good point:

Not every Laravel application will be using Jetstream... how will those people use Passport?

The given answer is rather disappointing to be honest:

Not every app needs third-party client registration. We're deprecating this feature in favor of a more modern, opt-in alternative —the Jetstream OAuth feature— where this functionality naturally fits.

Some apps need third-party client registration. There was a perfectly fine API for them …

Please reconsider the deprecation. If it's just simple CRUD code, it won't be too challenging to maintain this moving forward.

[hafezdivandari]

Jetstream and the new starter kits are very opinionated.

@hettiger The deprectated JSON API was very opinionated too. Also it wasn't customizable. The CRUD must be on the app side.

Some apps need third-party client registration. There was a perfectly fine API for them…

The ClientRepository class is not deprecated, you may see the sample implementation of client registeration on laravel/mcp package:

https://github.com/laravel/mcp/blob/232386959b7df5518484e2b7ccbb6b81451ff436/src/Server/Registrar.php#L105-L128

You may need to add other client metadata according to RFC7591: OAuth 2.0 Dynamic Client Registration Protocol.

If it's just simple CRUD code, it won't be too challenging to maintain this moving forward.

As mentioned above the current API implementation wasn't RFC compatible, not customizable and too opinionated.

[hettiger]

Jetstream and the new starter kits are very opinionated.

@hettiger The deprectated JSON API was very opinionated too. Also it wasn't customizable. The CRUD must be on the app side.

Some apps need third-party client registration. There was a perfectly fine API for them…

The ClientRepository class is not deprecated, you may see the sample implementation of client registeration on laravel/mcp package:

https://github.com/laravel/mcp/blob/232386959b7df5518484e2b7ccbb6b81451ff436/src/Server/Registrar.php#L105-L128

You may need to add other client metadata according to RFC7591: OAuth 2.0 Dynamic Client Registration Protocol.

If it's just simple CRUD code, it won't be too challenging to maintain this moving forward.

As mentioned above the current API implementation wasn't RFC compatible, not customizable and too opinionated.

We have very different opinions on this and that is totally fine — I understand your arguments from a technical perspective.

However, suggestions like

The ClientRepository class is not deprecated, you may see the sample implementation of client registeration on laravel/mcp package:

https://github.com/laravel/mcp/blob/232386959b7df5518484e2b7ccbb6b81451ff436/src/Server/Registrar.php#L105-L128

You may need to add other client metadata according to RFC7591: OAuth 2.0 Dynamic Client Registration Protocol.

and

Building the backend for this is a straightforward CRUD operation, which is simpler for developers to implement on their side (even by copy / pasting deprecated controllers) than feature bloating Passport.

are not user friendly at all. Passport offered these features for years. This is not about adding new features that might bloat the package. I think you're too focused on your own interests to be honest.

[hafezdivandari]

@hettiger I’m sorry to hear you feel that way. Passport is an open-source project, and I’m just a contributor trying to clarify the reasoning behind the current PR. If you believe a different approach would serve the package better, feel free to open a PR.

That said, it’s important that we stay aligned with RFC7591, and fully supporting that standard through built-in CRUD endpoints isn’t really practical IMHO.

[hettiger]

@hettiger I’m sorry to hear you feel that way. Passport is an open-source project, and I’m just a contributor trying to clarify the reasoning behind the current PR. If you believe a different approach would serve the package better, feel free to open a PR.

That said, it’s important that we stay aligned with RFC7591, and fully supporting that standard through built-in CRUD endpoints isn’t really practical IMHO.

Thank you for taking the time to answer in-depth on my feedback. Really appreciate it.