Защита моего REST API с помощью OAuth, при этом разрешена аутентификация через сторонних поставщиков OAuth (с использованием DotNetOpenAuth)

У меня есть продукт с простым REST API, поэтому пользователи продукта могут напрямую интегрироваться с функциями продукта без использования моего пользовательского веб-интерфейса.

Недавно меня заинтересовали различные третьи стороны по поводу интеграции их настольных клиентов с API, чтобы пользователи моего продукта могли получать доступ к своим данным с помощью этого стороннего приложения.

Я видел, что приложения, которые хотят использовать Twitter для аутентификации, используют страницу входа в Twitter, которая предоставляет конкретному приложению разрешение на доступ к данным этого пользователя. Вы нажимаете кнопку «Разрешить» или «Запретить», и процесс аутентификации завершается. Facebook использует тот же механизм, насколько я могу судить.

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

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

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

Может ли кто-нибудь дать мне хотя бы общий обзор шагов, которые мне нужно предпринять, или на что мне следует обратить внимание, чтобы это произошло? Или указать мне на какие-нибудь уроки? Или взорвать мое предложение и сказать, что я все (архитектурно) ошибаюсь?

Прежде всего хочу подчеркнуть разницу между аутентификацией и авторизацией:

А пользователь проверяет подлинность на вашем веб - сайте по поставке некоторых учетных данных , таких как имя пользователя + пароль. OpenID позволяет заменить это, аутентифицируя пользователя в другой службе, которая затем подтверждает личность пользователя на вашем веб-сайте от имени пользователя. Ваш сайт доверяет сторонней службе (поставщику OpenID) и поэтому считает, что пользователь вошел в систему.

Служба или приложение не проходит проверку подлинности на ваш веб - сайт - по крайней мере , как правило , не. Пользователь разрешает службе или приложению доступ к данным пользователя. Обычно это делается приложением, запрашивающим авторизацию поставщика услуг, затем отправляющим пользователя поставщику услуг, где пользователь сначала аутентифицируется (чтобы поставщик услуг знал, с кем он разговаривает), а затем пользователь говорит сайту «да, [приложение] может получить доступ к моим данным [некоторым ограниченным способом] ». С этого момента приложение использует токен авторизации.для доступа к данным пользователя на сайте поставщика услуг. Обратите внимание, что приложение не аутентифицирует себя, как если бы это был пользователь, но оно использует другой код, чтобы гарантировать службе, что она авторизована для доступа к данным конкретного пользователя.

Таким образом, после разъяснения этого различия вы можете принимать решения об аутентификации и авторизации на своем сайте совершенно независимо. Например, если вы хотите, чтобы ваши пользователи могли входить в систему, используя все: имя пользователя + пароль, OpenID и Facebook, вы можете это сделать. Совершенно ортогональное решение - это то, как вы авторизуете приложения (есть много протоколов, которые вы можете использовать для этого, OAuth, конечно, довольно популярен).

OpenID ориентирован на аутентификацию пользователей . OAuth ориентирован на авторизацию приложений . Однако некоторые службы, такие как Facebook и Twitter, решили использовать OAuth для аутентификации и авторизации вместо использования OpenID для аутентификации и OAuth для авторизации.

Что касается вашего собственного проекта, я настоятельно рекомендую вам проверить шаблон проекта веб-сайта ASP.NET MVC 2 OpenID (C #), доступный в VS Gallery. По умолчанию он поставляется с аутентификацией OpenID и поддержкой поставщика услуг OAuth. Это означает, что ваши пользователи могут входить в систему с помощью OpenID, а сторонние приложения и службы могут использовать OAuth для выполнения вызовов API на ваш веб-сайт и доступа к пользовательским данным.

Похоже, что вы захотите добавить в этот шаблон проекта, как только вы начнете работу, это возможность для ваших пользователей входить в систему с именем пользователя + паролем, а также с OpenID. Кроме того, если вы хотите, чтобы Facebook и Twitter были опцией для ваших пользователей, вы также должны реализовать это, поскольку они не используют стандарт OpenID. Но загрузка DotNetOpenAuth включает образцы для входа в Twitter и Facebook, так что у вас есть некоторые рекомендации.

Я подозреваю, что вам нечего будет делать на фронте авторизации. Как я уже говорил, он поставляется с OAuth, и этого, вероятно, вам будет достаточно.

Прежде всего. Вам нужно мысленно отделить ваш API от методов аутентификации.

Ваш API - это в основном ресурсы и методы для управления этими ресурсами. И у вас может быть несколько методов аутентификации доступа к вашему API.

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

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

Единственные реальные альтернативы OAuth, насколько я понимаю, - это OAuth 2.0 и простая базовая аутентификация.

Помимо этого, вы говорите об аутентификации с использованием Open-ID или идентификатора facebook и т. Д. Это еще один вопрос, который вам нужно задать себе. Но это действительно выходит за рамки API и OAuth. Для меня это больше похоже на вопрос создания пользователей в вашем сервисе. Я могу ошибаться.