Коли справа доходить до аутентифікації в Laravel, є багато варіантів. Але що ми повинні використовувати, коли справа доходить до аутентифікації вашого API?
Традиційно ми спиралися на щось на зразок веб-токенів JSON для нашої аутентифікації API, подібно до автентифікації на основі сеансу для Інтернету. Ви міняєте свої облікові дані на щось, що забезпечить вам тривалий доступ.
Потім ми почали використовувати Laravel Passport, фантастичну реалізацію OAuth, яку ви можете використовувати для надання OAuth доступу до ваших програм Laravel, будь то аутентифікація між серверами, мобільна аутентифікація або інші типи аутентифікації. Протягом тривалого часу ми дотримувалися використання Laravel Passport та типу Password Grant, що дозволило нам надсилати наші облікові дані разом із деталями програми OAuth, і ми повертали доступ та оновлювали токен, що дозволяло нам отримати доступ та оновити цей доступ після закінчення терміну його дії. Однак це більше не рекомендується як механізм аутентифікації, як ми звикли його використовувати.
Куди це нас покидає? Чи є Sanctum єдиним варіантом? Ну, і так, і ні. Sanctum був розроблений як легка альтернатива паспорту, але насправді він досяг набагато більшого. Незалежно від того, створюєте ви веб-додаток, клієнтську реалізацію або щось середнє - 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 в локальному сховищі.
