OAuth? , OpenID? Ни один? Какой из них должен поддерживать мой сайт?

Вы можете прочитать эта статья Малкома Трединника, в которой объясняется, что такое openid и oauth и что они делают. Они служат разным целям.

Таким образом, openid будет использоваться для уникальной идентификации пользователей - это решение для идентификации. oAuth предоставит средства для взаимодействия с данными, к которым имеют доступ пользователи вашего сайта, позволяя пользователю предоставлять вашему сайту временный доступ к внешним службам, например, к своей учетной записи flickr - это инструмент авторизации.

Конечно, всегда можно предложить только стандартную учетную запись для конкретного сайта, но ИМХО, поддержка openid лучше для ваших пользователей и для Интернета. Многие сайты, реализующие openid, позволяют пользователям использовать openid, если он у них есть, но также позволяют пользователям входить в систему и создавать учетные записи без openid. Так что это не обязательно предложение «или / или». Вы можете сделать и то, и другое!

Имейте в виду, что даже если вашему сайту не требуется доступ к личным данным ваших пользователей на других сайтах, OAuth все равно может применяться, если на вашем сайте есть данные, к которым пользователи могут захотеть получить доступ либо через API, либо с другого веб-сайта. При использовании OAuth к вашему сайту может применяться любой конец или оба.

Мое впечатление от OAuth таково, что он больше предназначен для обеспечения безопасного аутентифицированного доступа к API, а не для общего доступа пользователей.

Лично мне бы хотелось, чтобы больше сайтов поддерживали OpenID.

Я за поддержку интеграции авторизации пользователей с использованием OpenID, Facebook и любых других аутентификаторов. Предоставьте пользователю выбор.

ТАКЖЕ дайте им возможность не использовать их. В частности, на веб-сайтах, ориентированных на взрослых, ваши пользователи могут отказаться от чего-то, что не является таким анонимным, как простая регистрация на вашем веб-сайте. Просто используйте лучшие практики, когда дело доходит до хранения паролей.

Вы можете комбинировать их все и получать от этого максимум пользы, но это зависит от вашего выбора дизайна.

Например, если вы используете Java, вы можете настроить Acegi (Spring Security), чтобы разрешить openID вместе с вашим обычным механизмом аутентификации.

openID имеет расширения OAuth

OAuth имеет расширения openID

Тебе решать...

JanRain позволяет принимать примерно все. Учитывая, что крупные игроки всегда будут хотеть быть поставщиками, а не потребителями, это может быть единственным реалистичным «универсальным» вариантом.

Вот блестяще ясное объяснение. Исходя непосредственно из документации OAuth.

В предварительной версии для разработчиков с ноября 2011 г. имеется новый стандарт, называемый OpenID Connect. Он основан на OAuth 2.0 и Насколько я понимаю, стандартизирует способ работы Facebook, который также построен на OAuth 2.0. Это выглядит многообещающе, поскольку существует большой опыт работы с протоколом аутентификации Facebook и, возможно, это может быть решением, которое ищут многие веб-разработчики. Я еще не углублялся в это, поэтому могу неправильно понять это, но именно так я понял это после прочтения это сообщение в блоге об этом.