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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Я подозреваю, что у вас не будет особых действий на авторизации.Он приходит с OAuth, как я уже говорил, и этого, вероятно, будет достаточно для вас.

Answer 2

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

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

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

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

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

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