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

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

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

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

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

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

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

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

Ответ 1

Сначала я хотел бы подчеркнуть разницу между аутентификацией и авторизацией:

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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