Почему я должен использовать OpenID для аутентификации, а не OAuth?

Question

Я неоднократно читал, что OpenID лучше для аутентификации, чем OAuth (который предназначен для авторизации), включая несколько других постов на SO.* часто цитируемая статья.

Однако мне немного неясно, почему Я должен предпочесть OpenID для аутентификации, а не честного поставщика OAuth (например, Twitter или Facebook OAuth 2.0).Другие посты SO, которые я прочитал, объясняют различные варианты использования, и я понимаю разницу между тем, для чего предназначены протоколы, но они не объясняют, почему нельзя использовать OAuth для аутентификации.

Вот причины, по которым я могу прийти, и мои (возможно, ошибочные) ответы:

1. OAuth действительно для авторизации.Наличие аутентификации пользователей с использованием OAuth дает потребителю больше привилегий, чем им нужно.
   • Ответ. Обычно это так, но гораздо более ограниченно в случае детального OAuth (такого как Facebook), который позволяет мне запрашивать только минимальные разрешения.Фактически, многие сайты, такие как Facebook, предоставляют OAuth, но не OpenID, предположительно, потому что они больше заинтересованы в авторизации потребителей, чем в аутентификации клиентов.Если я хочу предоставить клиентам больше опций аутентификации, OAuth, кажется, дает мне это.
2. Сеансы OAuth имеют тенденцию жить дольше
   • Ответ: Не актуально, если я 'm намерение потребителя аутентифицировать клиентов;Я займусь своим собственным управлением сессиями и даже смогу сразу же избавиться от токенов OAuth, как только закончу аутентификацию своих пользователей.

Какие преимущества аутентификации предоставляет OpenIDпо сравнению с использованием крупномасштабных OAuth-провайдеров для аутентификации?

Answer 1

Главный вопрос, который вам нужно задать себе, - это заранее знать, каких поставщиков вы хотите поддержать. Если вы хотите разрешить пользователям использовать любого провайдера по своему усмотрению (с поддержкой OpenID, такого как Google, Yahoo, AOL и т. Д.), Вы должны использовать OpenID. Но если вы знаете, что большинство ваших пользователей захотят использовать Twitter, Facebook или других популярных поставщиков OAuth, используйте их.

Техническая терминология заключается в том, что OAuth обеспечивает делегированную аутентификацию, а OpenID обеспечивает федеративную аутентификацию. Теперь верно, что OAuth является протоколом авторизации, а не протоколом аутентификации, но, предоставив вам / me (Facebook) или / account / verify_credentials (Twitter), эти провайдеры расширили OAuth для использования в качестве протокола аутентификации.

Но вы не должны использовать OpenID. Это мертвый протокол.

Answer 2

Основная проблема с использованием OAuth для проверки подлинности заключается в том, что вам необходимо принять идентичность, основанную на доступе к данному ресурсу. В некоторых случаях это может быть допустимым предположением, но OAuth не гарантирует этого. Если доступ к ресурсу, который вы используете для аутентификации, делегирован другой стороне, и вы предполагаете, что идентификация основана на доступе к этому ресурсу, то это уязвимость, которая может позволить самозванцу пройти аутентификацию от имени другого подписчика. Это не имеет ничего общего с честностью поставщика OAuth или его отсутствием, а также с инструментом, для которого он не предназначен.

В случае Facebook OAuth может поддерживать аутентификацию, основанную только на подписчике, который может авторизовать приложение: если вы получаете авторизацию для доступа к профилю отдельного лица, это означает, что подписчик должен был пройти аутентификацию в Facebook. Похоже, это поддерживаемый вариант использования. Однако если позднее Facebook, например, позволяет другим приложениям или пользователям авторизовать ресурсы от имени своих подписчиков, то эта гарантия теряется.

В конечном счете, чтобы использовать OAuth для аутентификации, вам нужно сделать много предположений. Вы должны предположить, что пользователь, которого вы аутентифицируете, и только этот пользователь имеет право делегировать данный ресурс; Вы должны предположить, что полученные вами данные запроса достаточны для привязки к известной личности; Вы должны предположить, что механизм аутентификации был достаточен для аутентификации третьей стороне (что, если файл не был конфиденциальным и анонимный доступ мог быть предоставлен?); и вы должны предположить, что эти качества сохраняются со временем. OpenID построен специально для этого; OAuth нет.

Можете ли вы безопасно сделать эти предположения? В случае Facebook, возможно; они кажутся документированными и поддерживаемыми вариантами использования (я не знаком с конкретным API). Но, как правило, это не поддерживаемый вариант использования OAuth.