Во-первых, давайте проясним, что OAuth и OpenID - это две разные вещи.OpenID предназначен только для аутентификации .OAuth предназначен для аутентификации и авторизации.В этом случае авторизация относится к идее, что клиентское приложение авторизовано для доступа и обновления данных, связанных с аутентифицированным пользователем.
Что мне нужно сделать, так это разрешить третьемусторонние веб-сайты входят в учетную запись пользователя на веб-сайте, но только читают и записывают данные, которые принадлежат им, и не могут касаться данных, принадлежащих сторонним веб-сайтам?
Если данные, которыехранящиеся на каждом из сторонних веб-сайтов взаимоисключающие данные, хранящиеся на вашем сервере аутентификации, тогда вы можете придерживаться OpenID.
Если, однако, вы хотите, чтобы ваши сторонние веб-сайты обновляли информацию о пользователе, которую следует предоставлять всем другим сторонним веб-сайтам (например, имя, фамилия, почтовый адрес, информация о кредитной карте и т. Д.).), тогда вы можете пойти с OAuth.Я знаю, что есть расширение для спецификации OpenID, которое допускает подобные вещи (и, действительно, вы можете адаптировать это к своей собственной реализации), но в общем смысле этот вид вещей принадлежит OAuth.
Я немного нечеткий в деталях oAuth.Нужно ли создавать какой-то API-интерфейс или oAuth - единственное, что мне нужно реализовать?
Помимо первоначальных деталей запроса токенов и авторизации клиентского приложения с помощью сервера OAuth, вы могли быреализовать дополнительные методы для извлечения и обновления информации об аутентифицированном пользователе.Например, Twitter требует, чтобы ваше приложение было аутентифицировано с определенным пользователем и авторизовано для обновления статуса пользователя.Этот метод обновления состояния является частью их API в дополнение к базовой реализации OAuth.
Если я реализую oAuth, смогут ли другие сторонние веб-сайты иметь доступ к данным с веб-сайта?Кто-нибудь думает, что это плохая идея?да / нет и почему?
Этим веб-сайтам будет разрешен доступ только к данным пользователя, прошедшего аутентификацию на вашем OAuth-сервере, и авторизовали этот веб-сайт для доступа к своим данным.Однако только те веб-сайты, которые имеют действительный ключ потребителя, могут запрашивать соответствующие токены для начала сеанса OAuth.Таким образом, только те веб-сайты, которые вы авторизовали, смогут взаимодействовать с вашим сервером.
Всегда существует вероятность того, что эти токены могут быть взломаны с помощью Фиксация сеанса .Но это не должно помешать вам реализовать службу OAuth.Это не значит, не беспокойся об этом.Только не позволяйте этому быть препятствием.
Могу ли я позволить другим сторонним веб-сайтам регистрировать пользователя на главном веб-сайте без необходимости посещать основной веб-сайт?
Не с текущей спецификацией, определенной OAuth.Идея OAuth заключается в том, что ваши пользователи регистрируются на сервере OAuth.Ваши сторонние клиенты используют этот сервер в качестве точки аутентификации.Это не означает, однако, что вы не можете реализовать какой-то API для регистрации пользователя, если у приложения есть какая-то «основная» учетная запись для входа в систему (хотя это является собственной угрозой безопасности).Это просто не рекомендуется.
и как oAuth помогает мне убедиться, что сторонние веб-сайты не читают / не пишут / не изменяют пользовательские данные, относящиеся к сторонним веб-сайтам?
То, что вы используете OAuth, не означает, что ваши сторонние веб-сайты не могут хранить данные в своих собственных хранилищах данных.И Flickr, и Twitter предлагают сервисы OAuth, но не хранят информацию друг друга на своих серверах (фотографии из flickr не сохраняются в базах данных Twitter).
Пока вы не храните информацию, относящуюся к каждому приложению, на вашем сервере OAuth, у вас не должно быть проблем.Помните, что сервер OAuth предназначен для аутентификации пользователей и хранения основной информации, которая должна использоваться ВСЕМИ приложениями.Я повторю здесь, если все, что вы хотите сделать, это аутентифицировать пользователя, то придерживайтесь OpenID.
Редактировать
Могу ли я сегментировать разрешения такимчто, когда пользователь авторизует сайт A, он не авторизует его для своей полной учетной записи, а просто авторизует его для доступа к собственным данным своей учетной записи?Может ли oAuth сделать это?
В вашей реализации вы можете.Это будет вопрос проверки ключа потребителя, связанного с маркером доступа, который используется для доступа к этой конечной точке OAuth.Помните, что каждый вызов авторизованной части вашего API должен включать токен доступа.Поэтому имеет смысл, что если вы хотите заблокировать эту конечную точку для определенного приложения, вы бы проверили ее по токену доступа и ключу потребителя.