Усі три способи відповідають на питання «хто робить запит», але для різних клієнтів.
Сесійна cookie - браузерна автентифікація:
- користувач входить, сервер створює сесію і ставить cookie (
HttpOnly,Secure,SameSite); - браузер сам додає cookie до кожного запиту;
- для кого: власний фронтенд на тому ж домені (Blade, Livewire, Inertia, SPA через Sanctum);
- переваги: токен недоступний JavaScript (захист від крадіжки через XSS), вихід - знищити сесію на сервері;
- потребує захисту від CSRF - бо браузер надсилає cookie автоматично.
Токен доступу (bearer token) - автентифікація від імені користувача для небраузерних клієнтів:
Authorization: Bearer 1|AbCdEf...
- для кого: мобільні застосунки, десктоп, CLI, сторонні клієнти від імені користувача (OAuth);
- токени можна обмежити правами (scopes/abilities) і терміном дії, відкликати окремо для кожного пристрою;
- CSRF не загрожує - браузер сам токен не додає.
API-ключ - ідентифікація застосунку-інтегратора, а не людини:
- для кого: сервер-сервер інтеграції (партнер вивантажує замовлення, CRM синхронізує контакти);
- зазвичай довгоживучий, прив'язаний до облікового запису клієнта, з власними лімітами й правами;
- передається в заголовку (
AuthorizationчиX-Api-Key), ніколи в URL.
Типові помилки:
- токени в
localStorageдля власного SPA - будь-який XSS їх вкраде. Для SPA на своєму домені cookie-сесія безпечніша; - API-ключ у мобільному застосунку чи фронтенді - будь-хто дістане його з бандлу. Ключі - лише на серверах;
- токени без терміну дії і без можливості відкликання;
- ключі в Git, логах, URL - сканери публічних репозиторіїв знаходять їх за хвилини.
Як зберігати на сервері: як паролі - лише хеш (порівняння з хешем отриманого значення). Тоді витік бази не дає готових ключів. Так зберігає токени Laravel Sanctum (SHA-256).
Найпоширеніша вразливість API за OWASP - не спосіб автентифікації, а відсутність перевірки доступу до конкретного об'єкта після автентифікації.