ASP.NET MVC - формы Auth vs OAuth 2.0

Question

Я изучаю возможность использования OAuth 2.0 в будущих проектах.

Что я вижу, так это то, что OAuth построен на концепции [Владелец ресурса] + [Клиент веб-сайта] + [Сервер авторизации] + [Сервер ресурсов]. Многие статьи и учебные пособия в Интернете говорят об использовании Facebook, Twitter и т. Д. В качестве сервера авторизации/ресурсов, что все классно и хорошо.

То, что я пытаюсь мысленно изобразить, - это то, что я собираюсь создать свои собственные серверы Auth/Resource, почему я решил пойти этим путем? Каковы сценарии, которые в противном случае обычно не могут быть достигнуты с помощью аутентификации на основе форм ASP.NET MVC и модели атрибута [Авторизация]?

Answer 1

Взгляните на RFC 6749 - это говорит о случаях использования. Его хороший понятный RFC.

USECASE дословно из RFC:

o Third-party applications are required to store the resource 
     owner's credentials for future use, typically a password in 
     clear-text. 

    o Servers are required to support password authentication, despite 
     the security weaknesses inherent in passwords. 

    o Third-party applications gain overly broad access to the resource 
     owner's protected resources, leaving resource owners without any 
     ability to restrict duration or access to a limited subset of 
     resources. 

    o Resource owners cannot revoke access to an individual third party 
     without revoking access to all third parties, and must do so by 
     changing the third party's password. 

    o Compromise of any third-party application results in compromise of 
     the end-user's password and all of the data protected by that 
     password. 

Читать статью Аарона - OAuth2-Simplified

Недавно я узнал OAuth с помощью Apigee, вы можете использовать что-нибудь вроде Google API. Вот мой проект github oauth20_apigee, если он помогает оформлению заказа.

Answer 2

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

Однако всегда черти выступают и эта статья объясняет, почему OAuth может быть возможной sercurity отверстием в приложении, если не сделано правильно:

http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html

Answer 3

Это зависит от того, что ваших краткосрочных и долгосрочных целей будут. На мой взгляд, короткие и грязные моменты:

• OAuth 2.0, как правило, используется для предоставления доступа приложений к конкретным ресурсам от имени пользователя, который является отличным механизмом для обеспечения возможности 3-го приложения сторонних разработчиков расширить свой продукт. Поэтому, если вы создаете API, то это будет здорово для вас.
• Кроме того, это выгодно тем, что оно не только позволяет кому-то еще продлить ваш продукт, но и вы можете расширить их. Например, вы могли бы создать доверенное приложение для другого продукта, они могли бы связать своего клиента напрямую с вашим модулем (из-за отсутствия лучшего термина), не требуя отдельного входа в систему, если вы поддерживаете их формат токена (как правило, используя федеративный поставщик удостоверений)
• Если вы создаете приложение для поддержки аутентификации сторонних поставщиков OAuth, вы можете улучшить опыт пользователя для регистрации на вашем сайте. Позволяя им использовать свой выбор аутентификации (например, google, facebook, twitter и т. Д.), Им не нужно будет вводить много личной информации в течение миллиона миллионного времени. Вам просто нужно взять их аутентификацию и собрать любую дополнительную информацию, в которой вы нуждаетесь. Затем создайте для них внутреннюю учетную запись и свяжите их провайдера со своей учетной записью
• Вы можете эмулировать единый вход с помощью интегрированного IDP, что также повышает удобство использования.Например, если пользователь уже зарегистрировался в Google, ваш продукт может принять токен и просто запросить добавление дополнительной области к токену без необходимости повторного входа в систему.
• Реализация вашего собственного провайдера OAuth - это другой зверь, и я не уверен, что для него есть много пользы, если вы не планируете стать следующим Facebook или чем-то еще.