Когда дело доходит до аутентификации в Laravel, есть много вариантов. Но что мы должны использовать, когда дело доходит до аутентификации вашего API?
Традиционно мы полагаемся на что-то вроде веб-токенов JSON для аутентификации API, аналогично аутентификации на основе сеанса для Интернета. Вы обмениваете свои учетные данные на что-то, что предоставит вам длительный доступ.
Затем мы начали использовать Laravel Passport, фантастическую реализацию OAuth, которую вы можете использовать для предоставления OAuth-доступа к вашим приложениям Laravel, будь то аутентификация между серверами, мобильная аутентификация или другие типы аутентификации. В течение долгого времени мы придерживались использования Laravel Passport и типа Password Grant, что позволяло нам отправлять наши учетные данные вместе с данными приложения OAuth, и мы получали обратно токен доступа и обновления, что позволяло нам получать доступ и способ обновить этот доступ, когда срок его действия истек. Однако это больше не рекомендуется в качестве механизма аутентификации, как мы привыкли его использовать.
Что это оставляет нам? Является ли Sanctum единственным рекомендуемым вариантом? И да, и нет. Sanctum был разработан как легкая альтернатива Passport, но на самом деле он достиг гораздо большего. Независимо от того, создаете ли вы веб-приложение, реализацию клиента или что-то среднее - sanctum быстро стал золотым стандартом механизма аутентификации в экосистеме Laravel.
Но что это значит для API? Нужно ли нам передавать имя для токена каждый раз, когда мы хотим пройти аутентификацию? Что ж, вы можете это сделать - это никому не повредит. Однако как аутентифицировать API в Laravel?
Давайте рассмотрим мой подход и посмотрим, почему это работает/имеет смысл. Он начинается с учетных данных пользователей - как и любой подходящий механизм аутентификации. Мы публикуем их на наших конечных точках входа в систему или регистрации - и Laravel творит для нас волшебство (в зависимости от пакета, который мы используем).
Предположим, мы используем Laravel Breeze или Jetstream. В этом случае предоставленная аутентификация создаст для нас файл cookie на основе сеанса, который наша реализация затем может использовать для каждого последующего запроса, чтобы подтвердить его аутентифицированное состояние. Так вот, это меня немного смутило. Мне было интересно, где должен быть мой токен и что у меня есть на моей стороне, чтобы доказать, что я аутентифицирован, кроме файла cookie. Я настолько привык иметь дело с этим жетоном, что смог использовать его для подтверждения своей личности. Файлы cookie были для Интернета, верно? Я не рассматривал свой API как веб-API, что показывает, что мы все иногда можем быть немного наивными.
Предположим, я должен был создать приложение CLI, мобильное приложение или какую-то интеграцию, которая должна работать с моей локальной системой как что-то устанавливаемое. В этом случае мы можем использовать Sanctum для передачи имени для создания токена, который нуждается в хранении, что кажется естественным. Однако наш API может иметь интеграцию через одностраничное приложение или даже другое приложение, также встроенное в Laravel. Эта часть не имеет значения, так как это не то, что мы устанавливаем.
Лучший способ подойти к аутентификации — следовать тому, что я бы назвал простым руководством:
вы создаете что-то, к чему можно получить доступ, а не установить. В этой ситуации следует использовать Laravel Sanctum с аутентификацией на основе файлов cookie. Файл cookie может быть настроен так, чтобы он был настолько длинным или кратковременным, насколько это необходимо для вашего доступа, и когда доступ прекращается, аутентификация может сделать то же самое.
Вы создаете что-то, что установлено на устройстве пользователя. Здесь нам нужно сделать несколько вариантов. Является ли доступ чем-то, что необходимо контролировать на основе идентификации? Другими словами - есть ли у приложения доступ ко всему, и нет уровня авторизации? Laravel Passport, использующий учетные данные клиента, является хорошим выбором, если это так. В Laravel Passport есть тип гранта, называемый Client Credentials: где вы аутентифицируете клиента , а не пользователя , поэтому любой, кто имеет доступ к клиенту, может контролировать систему. Вы можете пойти немного дальше с PKCE, где вы не можете гарантировать конфиденциальность секрета клиента.
Если вам нужно аутентифицировать пользователя, а не клиента - тогда опирайтесь на Laravel Sanctum и передайте уникальное имя для установленного приложения - чтобы вы могли хранить предоставленный токен и использовать его повторно.
Самая большая проблема с использованием Laravel Sanctum заключается в том, что вы должны получить файл cookie межсайтового запроса, чтобы делать запросы к вашему API Laravel. При создании SPA это не проблема и является лучшим подходом, чем хранение веб-токена JSON в локальном хранилище.
