ДИСКЛЕЙМЕР: Это моя первая статья, я не являюсь опытным журналистом. Эта статья - просто возможность выговориться о наболевшем и поделиться опытом. Думаю, она будет обновляться походу моего дальнейшего углубления в тему. А пока что есть, что есть.
Введение
Последние несколько лет я занимаюсь тем, что учусь разрабатывать WEB-приложения. Мне знакомы различные подходы в этом деле, технологии, способы проектирования, от слов до полномасштабной реализации. Но долгое время я обходил стороной неприятное - аутентификация/авторизация. И это неслучайно, ведь данная тема отнюдь не является простой.
В интернете есть множество ресурсов, затрагивающих тему аутентификации, и облазив огромное количество из них я пришел к выводу, что каждый проект скорее всего будет иметь собственную, по своему завуалированную и причудливую систему аутентификации. Ее реализация будет зависеть от огромного числа факторов. Вот некоторые из них:
- Архитектура проекта (монолит? микросервисы?)
- Среда исполнения (нативная, веб)
- Масштабируемость (хотим ли мы легко интегрировать новый функционал?)
- И многое другое
Микросервисы
Следуя современным трендам в разработке ПО, сейчас популярна миркосервисная архитектура. Это статья не посвящена данной теме, но очень тесно с ней связана. Дело в том, что когда речь заходит о большом приложении, хочется создавать как можно более самостоятельные, универсальные, легко заменяемые решения.
OAuth 2.0
На сегодняшний день самым эталонным решением для аутентификации микросервисных приложений считается протокол OAuth 2.0.
Протокол OAuth 2.0 состоит из 4 сущностей:
- Защищенный ресурс (наш API)
- Владелец этого ресурса (конечный пользователь)
- Клиент - ПО, взаимодействующее с API от имени пользователя
- Сервер авторизации - ПО, обеспечивающее правами доступа Клиент
Пример: VK
Так как социальная сеть VK реализует данный протокол, рассмотрим его на их примере:
- Защищенный ресурс - мой профиль VK
- Владелец - я собственной персоной
- Клиент - Приложение VK, Vk Messanger, KateMobile, Vk Music и многие другие (в этом прелесть микросервисной архитектуры - множество разных приложений взаимодействуют с общим API, которое, кстати, может быть представлено как совокупность разных микросервисов)
- Сервер авторизации - для конечного пользователя выглядит как следующее окно:
Мое приложение
И так, рассмотрев протокол на чужом примере, попробуем реализовать его на своем собственном.
Предствим, что перед нами встала задача разработать приложение для знакомств. Как и в любом другом приложении, нам необходима авторизация, чтобы гарантировать безопасность данных у пользователей.
Все бы ничего, но как следует из картинки выше, нам необходимо сделать так, чтобы наше приложение работало в разных средах, то есть нам нужно несколько клиентов:
- Native - приложение на Android/IOS
- Web App - приложение, работающее в браузере
- Chat Bot - приложение, работающее поверх существующих мессенджеров (VK, Telegram и т.д.)
Стоит отметить, что ни одно из этих приложений не должно выставлять секретные данные пользователю, так как такой положение дел обеспечивает идеальные условия для хакерских атак. Если Native и Chat Bot априори гарантируют безопасность, то дела с Web App обостоят несколько иначе. Если рассматривать классические веб приложения с рендерингом на сервере (MVC), то безопасность обеспечивается с помощью cookie, но если речь зайдет об SPA, то тут становится интереснее.
Идея SPA заключается в том, что весь рендеринг страниц происходит не на стороне сервера, как раньше, а прямо в браузере пользователя. Такой подход смог обеспечить невероятный уровень интерактивности и повысить пользовательский опыт. Сайты стали живее. Но за все хорошее надо платить. И в данном случае речь идет об очень важном аспекте - безопасность. Дело в том, что JavaScript - это целый мастодонт из мира хакерских атак. Хранить пароли, токены и другие данные в локальном хранилище браузера - самое худшее, что вы можете сделать, разрабатывая свое приложение.
Благо для данной проблемы есть современное решение - SSR. Наиболее популярные фреймворки, которые одновременно дают всю мощь SPA, но и решают проблему безопасности, знакомые мне - это NextJS, NuxtJS, SvelteKit.
Именно это недоразумение, связанное с SPA, побудило меня написать эту статью.
И так, я сказал, что в браузерном JS мы не храним пароли. Тогда зачем на рисунке я отметил User's Browser?
В контексте OAuth 2.0, браузер пользователя служит как посредник между клиентом и сервером авторизации. В браузере пользователь осуществляет непосредственный вход в систему: вводит свои данные, которые затем отправляются на сервер авторизации
Мы используем браузер для этих целей неслучайно. Идея OAuth 2.0 заключается в том, что клиент не должен видеть секретные данные пользователя (пароли и т.д.), поэтому авторизация осуществляется не на клиенте, а именно в бразузере. Но почему браузер? Все дело в том, что протокол OAuth 2.0 работает только с использованием HTTP. Браузер умеет осуществлять редирект, что позваоляет нам обеспечить следующий механизм:
Пользователь впервые заходит в наше клиент приложение:
- Клиент видит, что пользователь неавторизован → происходит редирект к серверу авторизации
- Пользователь авторизуется → браузер производит редирект обратно в клиент, передавая токен, с которым клиент впоследсвии осуществяет запросы к API
Таким образом схема работы OAuth 2.0:
- Редирект пользователя в браузер
- Пользователь заполняет форму и отправляет данные к серверу авторизации
- Сервер авторизации убеждается, что введенные данные верны и отправляет ответ, в котором происходит редирект обратно в клиент вместе с токеном авторизации
- Клиент авторизован и может осуществлять запросы к защищенным маршрутам API