OAuth-авторизация против аутентификации
OAuth терминология беспокоит меня уже давно. Является ли авторизация OAuth такой, как некоторые предлагают, или это аутентификация?
Поправьте меня, если я ошибаюсь, но я всегда считал Авторизацию актом предоставления кому-либо доступа к ресурсу, хотя OAuth, похоже, не имеет какой-либо реализации, которая фактически предоставляет доступ пользователям к данному ресурсу. Все о реализации OAuth говорят о предоставлении пользователю токена (подписанного и иногда зашифрованного). Этот маркер затем передается при каждом вызове в конечную точку серверной службы, где он проверяется на достоверность, опять же, не является проблемой OAuth.
Является ли OAuth-аутентификация (каждая статья утверждает, что это не так), которая, как я понимаю, требует от пользователя предоставления учетных данных, что в свою очередь доказывает, что пользователь должен / не должен иметь доступ?
Таким образом, кажется, что OAuth не является авторизацией NOR Authentication, поскольку они должны выполняться другими процессами. Так какого черта это? Это процесс передачи токена? Это пуховое слово, которое на самом деле не имеет особого значения?
Трудно задать вопрос на эту тему, не представив загадочных и суеверных (призраков и гоблинов), поэтому я ожидаю, что ответить на этот вопрос тоже непросто. Входите на свой страх и риск.
2 ответа
OAuth - это спецификация для авторизации
OAuth 2.0 - это спецификация для авторизации, но НЕ для аутентификации. RFC 6749, 3.1. Конечная точка авторизации прямо говорит следующее:
Конечная точка авторизации используется для взаимодействия с владельцем ресурса и получения разрешения на авторизацию. Сервер авторизации ДОЛЖЕН сначала проверить личность владельца ресурса. Способ, которым сервер авторизации аутентифицирует владельца ресурса (например, имя пользователя и пароль для входа, сеансовые куки), выходитза рамки данной спецификации.
OAuth-аутентификация?
Аутентификация имеет дело с информацией о том, кто это. Авторизация имеет дело с информацией о том, "кто предоставляет кому какие разрешения". Процесс авторизации содержит аутентификацию в качестве первого шага. Это причина, по которой люди часто путаются.
Есть много библиотек и сервисов, которые используют OAuth 2.0 для аутентификации. Его часто называют "социальным логином", и это делает людей более запутанными. Если вы видите "OAuth-аутентификация" (не "OAuth-авторизация"), это решение, использующее OAuth для аутентификации.
OpenID Connect
OpenID 1.0 и OpenID 2.0 - это старые спецификации для аутентификации. Те, кто сделал спецификации, ожидали, что люди будут использовать OpenID для аутентификации. Однако некоторые люди начали использовать OAuth 2.0 для аутентификации (не для авторизации), и аутентификация OAuth быстро преобладает.
С точки зрения ребят из OpenID, аутентификация на основе OAuth не была достаточно безопасной, но они должны были признать, что люди предпочитают OAuth-аутентификацию. В результате ребята из OpenID решили определить новую спецификацию, OpenID Connect, поверх OAuth 2.0.
Да, это сильно запутало людей.
Определения OAuth 2.0 и OpenID Connect в одном предложении
OAuth 2.0- это инфраструктура, в которой пользователь службы может разрешить стороннему приложению получать доступ к своим данным, размещенным в службе, не раскрывая свои учетные данные (идентификатор и пароль) для приложения.
OpenID Connect- это фреймворк поверх OAuth 2.0, где стороннее приложение может получить идентификационную информацию пользователя, которая управляется службой.
(Извините, эти определения являются выдержками из обзорной страницы моей компании)
Определения с точки зрения разработчиков
Аутентификация - это процесс определения субъекта (= уникальный идентификатор) конечного пользователя. Есть много способов определить предмет. ID и пароль, отпечатки пальцев, распознавание радужной оболочки и т. Д.
Авторизация - это процесс, связывающий субъект с запрошенными разрешениями и клиентским приложением, которое запросило разрешения. Токен доступа представляет ассоциацию.
Смотрите также
OAuth — это протокол авторизации. Он не предназначен для аутентификации. Да, в процессе OAuth есть этап, на котором сервер идентификации аутентифицирует владельца ресурса. То, как это происходит, не относится к протоколу OAuth. Вот почему OAuth не заботится об аутентификации.
OAuth выполняет авторизацию, предоставляя токен доступа третьей стороне (поставщику услуг), и эта сторона сможет авторизовать доступ к ресурсу, предоставив токен.
Допустим, есть требование, согласно которому поставщик услуг хочет получить доступ к ресурсам (защищенным сервером идентификации) от имени владельца ресурса. Таким образом, владелец ресурса сначала пройдет аутентификацию, а затем предоставит поставщику услуг разрешение на доступ к конкретному ресурсу. Затем сервер идентификации выдаст токен доступа для поставщика услуг. Позже поставщик услуг может получить доступ к ресурсу с помощью этого токена.
Здесь OAuth не волнует, кто несет токен доступа или пытается получить доступ к ресурсам. Он проверяет токен доступа и позволяет третьей стороне получить доступ к ресурсам.