Почему OAuth само по себе не является структурой аутентификации?

Давайте начнем с определений, чтобы избежать путаницы. Аутентификация — это акт подтверждения истинности атрибута данных или сущности. Если я скажу, что я Прабат, мне нужно это доказать. Я могу доказать это с помощью чего-то, что я знаю, чего-то, что у меня есть, или чего-то, кем я являюсь. Как только я доказал себя тем, кем я себя считаю, система сможет мне доверять. Иногда системы не просто хотят идентифицировать меня по имени. По имени может помочь идентифицировать меня однозначно — но как насчет других атрибутов меня. Прежде чем пройти через контроль границы — вам нужно идентифицировать себя — по имени — по картинке — а также по отпечаткам пальцев и сетчатке глаза. Они проверяются в режиме реального времени по данным офиса VISA, который выдал вам визу. Эта проверка позволит убедиться, что тот же человек, который утверждал, что имеет визу, въезжает в страну. Это доказывает вашу личность. Подтверждение вашей личности — это аутентификация.

Авторизация — это то, что вы можете сделать. Ваши возможности Вы можете подтвердить свою личность на контроле границы по имени — по картинке — а также по отпечаткам пальцев и сетчатке глаза — но ваша виза решает, что вы можете сделать. Для въезда в страну вам необходимо иметь действующую ВИЗУ, срок действия которой еще не истек. Действительная виза не является частью вашей личности — но часть того, что вы можете сделать. Также то, что вы можете делать внутри страны, зависит от типа VISA. То, что вы делаете с B1 или B2, отличается от того, что вы можете делать с L1 или L2. Это авторизация.

OAuth 2.0 об авторизации. Не об аутентификации. OAuth 2.0 — это то, что вы можете сделать (или от имени другого пользователя), а не то, кем вы являетесь. Итак, вы не можете использовать OAuth 2.0 самостоятельно для аутентификации. Я слышу, что вы говорите. Мы используем логин Facebook на основе OAuth 2.0 для входа в различные веб-приложения. Так я вру? Давайте сами выберем Facebook для примера. Я получил следующее изображение из документации разработчика для входа в Facebook. Он выделяет поток OAuth с типом предоставления кода авторизации.

Пользователь заходит в веб-приложение. Нажатие на кнопку входа. Перенаправляется на Facebook для аутентификации и передает «код» клиентскому веб-приложению. Теперь веб-приложение обменивает код на токен доступа. Facebook выдаст токен доступа только для действительного кода. И — он также выдаст код только после аутентификации пользователя. Таким образом, веб-приложение, имеющее доступ к действительному токену доступа, означает — и это только означает — что конкретный пользователь из Facebook. Вот и все. Это похоже на проведение действительной VISA с печатью на панели управления без какой-либо идентификационной информации о пользователе. Глядя на маркер доступа — приложение не может сказать, кто пользователь, — оно может только сказать, откуда пользователь. Таким образом, это не помогает веб-приложению однозначно идентифицировать конечного пользователя. Когда тот же пользователь входит в систему в следующий раз, он может принести другой токен доступа — поэтому веб-приложение не может использовать токен доступа в качестве способа идентификации. Вот почему OAuth само по себе не является структурой аутентификации.

Вы все еще думаете, что я лгу? Конечно, вы делаете. Когда вы входите через Facebook — ваше приложение также получает определенные претензии о вас. Как ваше имя, фамилия и адрес электронной почты, а также ваш идентификатор Facebook. Как это происходит, если OAuth не приносит никаких атрибутов идентичности? Как только веб-приложение получает токен доступа от Facebook, чтобы получить атрибуты пользователя — веб-приложение может вызывать следующий API с полученным токеном доступа.

Это позволит получить идентификационную информацию пользователя, который авторизовал токен доступа. Теперь — это помогает идентифицировать пользователя или аутентифицировать пользователя. Но имейте в виду, что последний шаг выходит за рамки OAuth и эта функциональность предоставляется через API Graph Facebook. Не только через Graph API Facebook — даже через SCIM мы можем идентифицировать пользователя. Но с текущей спецификацией, кажется, есть ограничение в выполнении этого стандартным способом. С текущей спецификацией, чтобы получить детали конкретного пользователя, мы используем следующее.

Но сразу после потока OAuth — у нас есть только токен доступа на стороне клиента. Нет конкретной информации о конечном пользователе. Поэтому мы не можем использовать вышеизложенное. Имея предопределенный ИД пользователя, скажем «я» [как в Facebook Graph API], — можно сделать так, чтобы он возвращал информацию о зарегистрированном пользователе.

В приведенном выше случае информация о пользователе, соответствующая предоставленному токену на предъявителя, будет возвращена обратно. Таким образом, исходя из этого, клиент может идентифицировать конечного пользователя по его атрибутам. Помимо двух вышеупомянутых подходов — OpenID Connect — лучший, построенный на основе OAuth 2.0 для идентификации конечного пользователя.

С OpenID Connect в дополнение к токену доступа OAuth — клиент или веб-приложение также получают токен ID. Идентификационный токен — это токен безопасности, который содержит утверждения / идентификационную информацию о событии аутентификации и другие запрошенные утверждения от клиента. Идентификационный токен представляется в виде JWT — и его можно использовать для подтверждения личности конечного пользователя.

Ссылка: Почему OAuth само по себе не является структурой аутентификации? от нашего партнера JCG Прабата Сиривардены в блоге Facile Login .