API Аутентификация в Laravel

Традиционно мы опирались на что-то вроде JSON Web Токенов для аутентификации API, подобно аутентификации на основе сеансов в Интернете. Вы обмениваете свои учётные данные на что-то, что обеспечит вам длительный доступ.

Затем мы начали использовать Laravel Passport, фантастическую реализацию OAuth, которую вы можете использовать для предоставления OAuth-доступа к вашим приложениям Laravel, будь то аутентификация между серверами, мобильная аутентификация или другие типы аутентификации. В течение долгого времени мы использовали Laravel Passport и тип Password Grant, который позволял нам отправлять наши учётные данные вместе с деталями OAuth-приложения, а в ответ мы получали маркер доступа и обновления — доступ и способ обновить его по истечении срока действия. Однако этот механизм больше не рекомендуется в качестве механизма аутентификации, как мы его использовали.

Что же нам остаётся? Является ли Sanctum единственным рекомендуемым вариантом? И да, и нет. Sanctum был разработан как лёгкая альтернатива Passport, но в действительности он достиг гораздо большего. Создаёте ли вы веб-приложение, клиентскую реализацию или что-то среднее между ними — Sanctum быстро стал золотым стандартом механизма аутентификации в экосистеме Laravel.

Однако что это означает для API? Нужно ли нам передавать имя для токенов каждый раз, когда мы хотим пройти аутентификацию? Ну, вы можете это сделать — это никому не повредит. Однако как мне аутентифицировать свои API в Laravel?

Давайте рассмотрим мой подход и поймём, почему это работает/имеет смысл. Все начинается с учётных данных пользователей — как в любом подходящем механизме аутентификации. Мы отправляем их в конечные точки входа или регистрации — и Laravel делает за нас некоторую магию (в зависимости от используемого пакета).

Предположим, мы используем Laravel Breeze или Jetstream. В этом случае аутентификация создаст для нас основанный на сессии куки-файл, который наша реализация сможет использовать при каждом последующем запросе для подтверждения своего аутентифицированного состояния. Это меня немного смутило. Мне было любопытно, где должен находиться мой токен и что у меня есть на моей стороне, чтобы доказать, что я аутентифицирован, кроме куки. Я настолько привык иметь дело с этим токеном или тем токеном, что мог использовать его для подтверждения своей личности. Куки были для Интернета, верно? Я не воспринимал свой API как веб-API, что показывает, что все мы иногда можем быть немного наивными.

Предположим, мне нужно создать CLI-приложение, мобильное приложение или какую-то интеграцию, которая должна работать с моей локальной системой как нечто устанавливаемое. В этом случае мы можем использовать Sanctum для передачи имени, чтобы создать токен, который нужно хранить — что кажется естественным. Однако наш API может иметь интеграцию через одностраничное приложение — или даже другое приложение, также построенное на Laravel. Эта часть не имеет значения, поскольку это не то, что мы устанавливаем.

Лучше всего подходить к проверке подлинности, следуя тому, что я бы назвал простым руководством:

Вы создаёте что-то, к чему получают доступ, а не устанавливают. В этой ситуации вам следует использовать Laravel Sanctum с аутентификацией на основе куки. Куки можно настроить так, чтобы они были настолько длительными или кратковременными, насколько вам нужен доступ, и когда доступ прекращается, аутентификация тоже может быть прекращена.

Вы создаёте что-то, что устанавливается на устройство пользователя. Здесь нам нужно принять несколько решений. Является ли доступ чем-то, что необходимо контролировать на основе идентификации? Другими словами — приложение имеет доступ ко всему, и нет уровня авторизации? Laravel Passport с использованием учётных данных клиента — хороший выбор в этом случае. Laravel Passport имеет тип гранта под названием Client Credentials: где вы аутентифицируете клиента, а не пользователя — поэтому тот, кто имеет доступ к клиенту, может контролировать систему. Вы можете пойти немного дальше, используя PKCE, где вы не можете гарантировать конфиденциальность секрета клиента.

Если вам нужно аутентифицировать пользователя, а не клиента — тогда опирайтесь на Laravel Sanctum и передавайте уникальное имя для установленного приложения — так вы сможете хранить предоставленный токен и использовать его многократно.

Самая большая проблема с использованием Laravel Sanctum заключается в том, что для выполнения запросов к API Laravel необходимо получать межсайтовый куки-запрос. При создании SPA это не проблема, и это лучший подход, чем хранение JSON веб-токена в локальном хранилище.