Почему я должен использовать OpenID для аутентификации, а не OAuth?
Я неоднократно читал, что OpenID лучше для аутентификации, чем OAuth (который предназначен для авторизации), включая несколько других сообщений на SO.
Похоже, что это также сделано в this часто цитируемая статья.
Однако я немного не понимаю , почему я должен отдавать предпочтение OpenID для аутентификации, а не честному провайдеру OAuth (например, Twitter или Facebook OAuth 2.0). Другие сообщения SO, которые я прочитал, объясняют различные варианты использования, и я понимаю разницу между тем, для чего предназначены протоколы, но они не объясняют, почему нельзя использовать OAuth для аутентификации.
Вот причины, которые я могу придумать, и мои (возможно, ошибочные) ответы:
- OAuth действительно предназначен для авторизации. Аутентификация пользователей с использованием OAuth дает потребителю больше привилегий, чем им нужно.
- Ответ: В целом это правда, но гораздо более ограничено в случае детализированного протокола OAuth (например, предоставляемого Facebook), который позволяет мне запрашивать только минимальные разрешения. Фактически, многие сайты, такие как Facebook, предоставляют OAuth, но не OpenID, предположительно потому, что они больше заинтересованы в авторизации потребителей, чем в аутентификации клиентов. Если я хочу предоставить клиентам больше вариантов аутентификации, OAuth, кажется, дает мне это.
- Сессии OAuth, как правило, живут дольше
- Ответ: Не актуально, если я потребитель, намеревающийся аутентифицировать клиентов; Я сам буду управлять сеансом и могу даже избавиться от токенов OAuth сразу же, как только закончу аутентификацию своих пользователей.
Какие преимущества аутентификации дает OpenID по сравнению с использованием крупномасштабных поставщиков OAuth для аутентификации?
1 ответ
Фундаментальная проблема с использованием OAuth для аутентификации заключается в том, что вам необходимо принять идентичность на основе доступа к данному ресурсу. В некоторых случаях это может быть допустимым предположением, но OAuth не гарантирует этого. Если доступ к ресурсу, который вы используете для аутентификации, делегирован другой стороне, и вы предполагаете, что идентификация основана на доступе к этому ресурсу, то это уязвимость, которая может позволить самозванцу пройти аутентификацию от имени другого подписчика. Это не имеет ничего общего с честностью провайдера OAuth или его отсутствием, а также с инструментом, для которого он не предназначен.
В случае Facebook OAuth может поддерживать аутентификацию, основанную только на подписчике, который может авторизовать приложение: если вы получаете авторизацию для доступа к профилю пользователя, это означает, что подписчик должен был пройти аутентификацию в Facebook. Похоже, это поддерживаемый вариант использования. Однако, если позже Facebook, например, позволит другим приложениям или пользователям авторизовать ресурсы от имени своих подписчиков, то эта гарантия теряется.
В конечном счете, чтобы использовать OAuth для аутентификации, вам нужно сделать много предположений. Вы должны предположить, что пользователь, которого вы аутентифицируете, и только этот пользователь имеет право делегировать данный ресурс; Вы должны предположить, что полученные вами данные запроса достаточны для привязки к известной личности; Вы должны предположить, что механизм аутентификации был достаточен для аутентификации третьей стороне (что, если файл не был конфиденциальным и анонимный доступ мог быть предоставлен?); и вы должны предположить, что эти качества сохраняются со временем. OpenID построен специально для этого; OAuth нет.
Можете ли вы безопасно сделать эти предположения? В случае Facebook, возможно; они кажутся документированными и поддерживаемыми вариантами использования (я не знаком с конкретным API). Но, как правило, это не поддерживаемый вариант использования OAuth.