Перевод первой части статьи «Authorization and Authentication For Everyone».
Аутентификация и авторизация необходимы во многих приложениях. Возможно, вам тоже случалось создавать приложения и реализовывать в них авторизацию. Скажем, путем импорта сторонней библиотеки для аутентификации или с использованием платформы идентификации.
Возможно, вы выполнили поставленную задачу, но так и не поняли до конца, что, собственно, происходит за кулисами и почему все делается именно так, как делается. Если хотите по-настоящему разобраться, что происходит под капотом, когда вы используете OAuth 2.0 и стандарты OpenID, прочтите эту статью до конца!
Аутентификация это сложно. Почему? Стандарты аутентификации хорошо определены, но не так легко все правильно понять. И это нормально! Мы рассмотрим концепцию идентичности шаг за шагом, наращивая при этом наши знания. К концу прочтения статьи у вас будет хороший фундамент и вы будете знать, какую тему хотите изучить глубже.
Эта статья предназначена для прочтения от начала до конца. Каждая новая тема разбирается на основе уже разобранных — учитывайте это, если захотите перескочить раздел.
Вступление
Когда я говорю родственникам или друзьям, что «занимаюсь вопросами проверки личности», они часто думают, что я работаю в госструктуре и помогаю людям решать проблемы с водительскими правами или ловить мошенников, ворующих деньги с кредитных карт.
Но это не так. Раньше я работала в Auth0 — компании, занимающейся вопросами цифровой идентичности. Сейчас я член программы Auth0 Ambassadors и разработчик-эксперт в Google по направлению SPPI (Security, Privacy, Payments, and Identity — «безопасность, приватность, платежи и идентичность»).
Цифровая идентичность
Цифровая идентичность это набор атрибутов, определяющих отдельного пользователя в контексте функции определенного приложения.
Что это значит?
Скажем, у вас есть онлайн-магазин по продаже обуви. Цифровой идентичностью пользователей вашего приложения может быть номер кредитной карты, адрес доставки и история покупок. Их цифровая идентичность рассматривается в контексте вашего приложения. Это подводит нас к следующей теме…
Аутентификация
В широком смысле аутентификация это процедура проверки, является ли пользователь тем, за кого себя выдает. Когда система установила, что пользователь, назвавшийся Колей, и в самом деле Коля, можно переходить к следующему шагу…
Авторизация
Авторизация связана с предоставлением доступа к определенным ресурсам или с отказом в таком доступе.
Стандарты
Я уже говорила, что аутентификация имеет хорошо определенные стандарты. Но кто их определяет, откуда они берутся?
То, как все работает в интернете, определяется большим количеством разных стандартов и организаций. В контексте аутентификации и авторизации нас интересуют Инженерный совет Интернета (Internet Engineering Task Force, IETF) и OpenID Foundation (OIDF).
Инженерный совет Интернета
IETF это большое, открытое, международное сообщество проектировщиков, ученых, сетевых операторов и провайдеров, которые занимаются вопросами развития архитектуры интернета и тем, чтобы в интернете все работало без сбоев.
Если говорить попроще, профессионалы объединились для написания технических документов, определяющих, как все в интернете должно делаться.
OpenID Foundation (OIDF)
OIDF это неприбыльная международная организация, в которую входят отдельные люди и целые компании. Члены этой организации занимаются продвижением и защитой технологий OpenID.
Теперь, когда мы знаем кое-что о спецификациях и о том, кто их пишет, давайте вернемся к теме авторизации и поговорим о…
OAuth 2.0
OAuth 2.0 это одна из наиболее часто упоминаемых спецификаций, когда дело касается веба. Но при этом ее столь же часто неправильно понимают.
OAuth не является спецификацией аутентификации.
OAuth имеет дело с делегированной авторизацией. Вы помните, что аутентификация — это проверка личности пользователя. Авторизация касается предоставления доступа к ресурсам или отказа в доступе. OAuth 2.0 дает возможность получить доступ к приложениям от имени пользователей. (Не волнуйтесь, аутентификацию мы тоже рассмотрим!)
До Oauth
Чтобы понять суть и назначение Oauth, нужно вернуться назад во времени. OAuth 1.0 был представлен в декабре 2007 года. Но до того, если нам нужен был доступ к сторонним ресурсам, выглядело все следующим образом:
Скажем, вы используете приложение с названием HireMe123. HireMe123 хочет добавить событие в вашем календаре (например, запись на собеседование). То есть, это приложение хочет осуществить действие от имени пользователя. Но HireMe123 не имеет собственного календаря. Для добавления событий это приложение хочет воспользоваться сторонним сервисом — MyCalApp.
Когда вы логинитесь в HireMe123, HireMe123 спрашивает у вас данные для доступа в MyCalApp. В результате вы вводите свой логин и пароль для MyCalApp на сайте HireMe123.
После этого HireMe123 использует ваш логин с паролем от MyCalApp, чтобы получить доступ к API MyCalApp. После этого приложение HireMe123 сможет создавать события в календаре, используя при этом ваши полномочия.
Но разглашать логин и пароль это плохо!
Весь этот подход основан на том, что пользователь выдает свои логин с паролем от одного приложения совершенно другому приложению, а это не хорошо. Почему?
Во-первых, HireMe123 намного меньше заинтересован в защите вашего логина и пароля к MyCalApp. Если HireMe123 не защитит эти ваши данные должным образом и они утекут или будут украдены, кто-то может написать об этом разгромные статьи в блогах. Но HireMe123 это не заденет, по крайней мере, для них не будет таких катастрофических последствий, как для MyCalApp.
Во-вторых, HireMe123 также получает слишком много прав доступа к MyCalApp. У этого приложения получается такой же уровень прав, как у вас самого, потому что для получения доступа оно пользуется вашим логином и паролем. Это означает, что HireMe123 может читать ваши календарные события, удалять их, изменять настройки календаря и т. п.
И тут появляется Oauth
OAuth 2.0 это открытый стандарт для осуществления делегированной авторизации. Это спецификация, которая говорит нам, каким образом нужно предоставлять сторонним приложениям доступ к API без разглашения паролей пользователей.
Используя OAuth, пользователь может поручить HireMe123 вызвать MyCalApp от имени пользователя. MyCalApp может ограничить доступ к своему API, когда его вызывают сторонние клиенты, не рискуя выдать логины с паролями или предоставить слишком много прав. Это достигается благодаря тому, что используется…
Сервер авторизации
Сервер авторизации это набор конечных точек (endpoints) для взаимодействия с пользователем и выпуска токенов.
Давайте вернемся к ситуации с HireMe123 и MyCalApp, только теперь с учетом наличия OAuth 2.0:
Теперь у MyCalApp есть сервер авторизации. Предположим, что приложение HireMe123 уже зарегистрировалось в качестве известного клиента в MyCalApp, то есть, сервер авторизации MyCalApp распознает HireMe123 в качестве сущности, которая в принципе может запрашивать доступ к его API.
Предположим также, что вы уже залогинились в HireMe123 с помощью любой системы аутентификации, которую установило для себя это приложение. Теперь HireMe123 хочет создавать события в календаре от вашего имени.
HireMe123 посылает запрос авторизации к серверу авторизации MyCalApp. В ответ сервер авторизации MyCalApp предлагает вам — пользователю — залогиниться в MyCalApp (если вы еще не входили в систему). Вы проходите аутентификацию на MyCalApp.
После этого сервер авторизации MyCalApp запрашивает у вас согласие на то, что HireMe123 получит доступ к API MyCalApp от вашего имени. Происходит это следующим образом:
- В браузере откроется приглашение.
- В нем у вас запросят согласие на то, чтобы приложение HireMe123 получило возможность добавлять события в календарь (и только это, ничего кроме этого!).
- Если вы скажете «да» и зафиксируете свое согласие, сервер авторизации MyCalApp пошлет HireMe123 код авторизации. Таким образом HireMe123 узнает, что пользователь MyCalApp (т. е., вы) точно согласился разрешить HireMe123 добавлять события, используя пользовательский (ваш) MyCalApp.
После этого MyCalApp выпустит токен доступа для HireMe123. HireMe123 сможет использовать этот токен доступа для вызова MyCalApp API в рамках данных вами прав (в нашем случае — для добавления событий в ваш календарь через MyCalApp API).
При этом не происходит ничего опасного! MyCalApp просит пользователя залогиниться. HireMe123 не просит пользователя выдать свой логин и пароль от MyCalApp. Больше нет никаких проблем с излишними правами доступа или разглашением логина и пароля.
Как насчет аутентификации?
На этом этапе, я надеюсь, вам стало ясно, что OAuth — это про делегированный доступ. Это не про аутентификацию. Там, где в этом процессе происходила аутентификация, мы логинились по процедуре, реализованной HireMe123 или MyCalApp по своему усмотрению. OAuth 2.0 не прописывал, как это должно быть сделано: он «занимается» только авторизацией доступа сторонних API.
Так почему же аутентификацию частенько связывают с OAuth?
Это мы рассмотрим в следующей части статьи.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]