Ответ
OAuth 2.0 — это протокол авторизации, позволяющий приложениям получать ограниченный доступ к данным пользователя на других сервисах без передачи логина и пароля.
Основные роли:
- Resource Owner — пользователь
- Client — приложение, запрашивающее доступ
- Authorization Server — сервис, выдающий токены (например, Google, Facebook)
- Resource Server — API, защищающее данные
Типы потоков (grant types):
- Authorization Code — для серверных приложений
- Implicit (устарел) — для SPA
- Client Credentials — для сервис-сервис авторизации
- Refresh Token — обновление токена
Пример запроса кода авторизации:
const authUrl = `https://auth-server.com/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read_profile`;OAuth 2.0 использует токены (access_token, refresh_token) вместо паролей, что безопаснее.
Ответ 18+ 🔞
Давай разберём этот ваш OAuth 2.0, а то как послушаешь — кажется, что там ядерная физика, а на деле проще пареной репы, если вникнуть.
Представь, ты заходишь в приложение «Фотки от Васёчка», и оно такое: «Хочу твои фотки из Инстаграмма!». Раньше бы пришлось отдавать логин и пароль, а это, простите, как отдать ключи от квартиры первому встречному бомжу. Пиздец, а не безопасность.
Так вот, OAuth 2.0 — это такой протокол, который позволяет приложению легально подлизаться к твоим данным на другом сервисе, но без твоего пароля. Красота же!
Кто тут главные по тарелкам:
- Resource Owner (Владелец ресурса) — это ты, пользователь, со своими фотками, письмами и прочим цифровым добром.
- Client (Клиент) — это то самое приложение-нахлебник («Фотки от Васёчка»), которое охочее до твоих данных.
- Authorization Server (Сервер авторизации) — это, типа, главный вышибала и бюрократ в одном лице (например, сервера Google или Facebook). Он решает, пускать или нет, и выдает пропуска.
- Resource Server (Сервер ресурсов) — это уже конкретный склад с данными (API Инстаграмма), который охраняется этими пропусками.
А теперь про «потоки» (grant types), это как разные способы пролезть на тусовку:
- Authorization Code (Код авторизации) — классика для взрослых. Для приложений, у которых есть свой сервер (бэкенд). Самый безопасный, потому что токен сразу на сервер идёт, а не болтается в браузере.
- Implicit (Неявный) — этот, вроде как, для одностраничных приложений (SPA), но его сейчас все хают и считают устаревшим, потому что токен может светиться в адресной строке. Доверие к нему — ноль ебать.
- Client Credentials (Учетные данные клиента) — когда два сервиса между собой договариваются, без участия живого юзера. Типа, «я — микросервис А, пусти меня к API микросервиса Б».
- Refresh Token (Токен обновления) — это не отдельный поток, а такая хитрая жопа. У access_token жизнь короткая, а refresh_token живёт дольше и может выпросить новый access_token, когда старый сдохнет. Удобно, чтобы пользователя каждый час не гонять по новой.
Вот смотри, как обычно начинается этот цирк (запрос кода):
const authUrl = `https://auth-server.com/authorize?
response_type=code&
client_id=CLIENT_ID&
redirect_uri=CALLBACK_URL&
scope=read_profile`;Объясняю на пальцах: приложение формирует ссылку, ты по ней кликаешь, тебя перекидывает к вышибале (Authorization Server), а тот спрашивает: «Чувак, приложение «Васёчек» хочет доступ к твоему профилю. Пущай?». Ты говоришь «Ага», и тебя с кодом (не токеном ещё!) отправляют обратно в приложение. А уж потом это приложение тихонечко, со своей закрытой стороны, меняет этот код на настоящий access_token.
И вся фишка в том, что работа идёт с этими самыми токенами, а пароль твой остаётся при тебе. Безопаснее, удобнее. В общем, не протокол, а ебушки-воробушки! Главное — потоки не перепутать, а то получится пиздопроебина вместо авторизации.