Введение в общий поставщик OAuth ASP.NET 5

1. Вступление
2. Поток OAuth
3. Настройка проекта ASP.NET
4. Заключение

Опубликовано: 14 апреля 2015 г.

Вступление

За последние 2 года я принимал участие в OWin провайдеры аутентификации проект, который позволяет разработчикам разрешать пользователям своих приложений ASP.NET входить в систему с помощью широкого спектра сервисов, таких как GitHub, LinkedIn, Yahoo и других.

Он начался с публикации в блоге о том, как разрешить пользователям входить в свои учетные записи Google+ через OAuth, а затем перешел к LinkedIn и Yahoo, и вскоре появился пакет Nuget, и число провайдеров выросло до его уровня. 23 сегодня.

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

Это было то, что почти каждый сотрудник библиотеки заметил и прокомментировал.

К счастью, в ASP.NET 5 ребята из Microsoft разработали универсального поставщика OAuth, который можно легко настроить для работы с большинством сервисов.

Я пишу пару постов в блоге, которые будут охватывать следующее: 1. Обзор нового универсального поставщика OAuth и как его настроить (этот пост в блоге) 2. Некоторые более сложные сценарии конфигурации

Я пишу эти посты в блоге с помощью Visual Studio CTP 6 и ASP.NET 5 Beta 3. С этого момента ситуация неизбежно изменится, поэтому, если вы читаете это через несколько месяцев, надеюсь, что все еще достаточно знакомы для вас чтобы понять их.

Поток OAuth

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

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

В этом посте я покажу, как настроить аутентификацию с GitHub, поэтому ради этого поста в блоге подумайте о GitHub как о сервис-провайдере.

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

Что касается фактического потока OAuth 2, он выглядит следующим образом:

1. Потребитель отправляет запрос конечной точке авторизации поставщика услуг на авторизацию пользователя.
2. Поставщик услуг аутентифицирует пользователя и запрашивает, разрешать ли Потребителю доступ к его информации.
3. Если пользователь авторизует Потребителя, Поставщик услуг перенаправляет обратно на URI перенаправления на веб-сайте Потребителя с временным кодом доступа.
4. Потребитель вызывает конечную точку токена на веб-сайте поставщика услуг для обмена кодом на более постоянный токен доступа.
5. Поставщик услуг предоставляет токен доступа, который может использоваться для аутентификации последующих запросов к защищенным ресурсам.

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

В приведенном выше разделе я выделил важные части, необходимые для настройки универсального поставщика OAuth, выделенным жирным шрифтом . Это: 1. Идентификатор клиента 2. Секрет клиента 3. URI перенаправления 4. Конечная точка авторизации 5. Конечная точка токена

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

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

URI перенаправления - это то, что вы можете указать при настройке аутентификации OAuth на приемнике. Это должно совпадать с тем, что вы указали при создании приложения в сервис-провайдере. Обычно это будет называться либо URL-адресом перенаправления, либо URL- адресом обратного вызова, либо каким-либо другим вариантом.

Используя наш пример GitHub, эту информацию можно найти в разделе OAuth документации API по адресу https://developer.github.com/v3/oauth/

Вы увидите, что они перечисляют конечную точку авторизации как

https://github.com/login/oauth/authorize

и конечная точка токена как

https://github.com/login/oauth/access_token

Конечная точка авторизации обычно имеет путь / авторизация, / аутентификация, / аутентификация или что-то подобное. Конечная точка Token обычно имеет путь / access_token или / token, так что следите за ними.

Настройка проекта ASP.NET

Поскольку шаблон проекта ASP.NET 5 по умолчанию еще не поддерживает встроенные логины в социальных сетях, я основываю свой код на SocialSample project в репозитории безопасности ASP.NET на GitHub. Я просто создал пустой проект ASP.NET 5 и выполнил упражнение на копирование и вставку из проекта SocialSample для правильной загрузки:

открытый класс Startup {public void ConfigureServices (IServiceCollection services) {services.AddDataProtection (); services.Configure <ExternalAuthenticationOptions> (options => {options.SignInAsAuthenticationType = CookieAuthenticationDefaults.AuthenticationType;}); } public void Configure (приложение IApplicationBuilder) {app.UseCookieAuthentication (options => {options.LoginPath = new PathString ("/ login");}); // Здесь мы настроим GitHub ... // ... // Выберите тип аутентификации app.Map ("/ login", socialApp => {socialApp.Run (async context => {string authType = context. Request.Query ["authtype"]; if (! String .IsNullOrEmpty (authType)) {context.Response.Challenge (new AuthenticationProperties () {RedirectUri = "/"}, authType); return;} context.Response.ContentType = "text / html"; await context.Response.WriteAsync ("<html> <body>"); await context.Response.WriteAsync ("Выберите тип аутентификации: <br>"); foreach (тип var в context.GetAuthenticationTypes ()) {await context.Response.WriteAsync ("&lt;a href=\"?authtype=" + type.AuthenticationType + "\">" + (type.Caption ?? "(исключено)") + "</ a > <br> ");} ожидание context.Response.WriteAsync (" </ body> </ html> ");});}); // Выйти, чтобы удалить куки пользователя. app.Map ("/ logout", socialApp => {socialApp.Run (async context => {context.Response.SignOut (CookieAuthenticationDefaults.AuthenticationType); context.Response.ContentType = "text / html"; ожидайте context.Response. WriteAsync ("<html> <body>"); ожидайте context.Response.WriteAsync ("Вы вышли из системы. До свидания" + context.User.Identity.Name + "<br>"); ожидайте context.Response.WriteAsync. ("<a href=\"/\"> Главная страница </a>"); ожидайте context.Response.WriteAsync ("</ body> </ html>");});}); // Запретить анонимный запрос за пределами этой точки. app.Use (async (context, next) => {if (! context.User.Identity.IsAuthenticated) {// Промежуточное программное обеспечение cookie перехватит этот 401 и перенаправит на / login context.Response.Challenge (); return;} ждать следующего ();}); // Отображение информации о пользователе app.Run (async context => {context.Response.ContentType = "text / html"; await context.Response.WriteAsync ("<html> <body>"); await context.Response.WriteAsync ( "Hello" + context.User.Identity.Name + "<br>"); foreach (утверждение var в context.User.Claims) {ожидание context.Response.WriteAsync (Clamp.Type + ":" + Claim.Value + "<br>");} ожидание context.Response.WriteAsync ("<a href=\"/logout\"> Выйти </a>"); ожидание context.Response.WriteAsync ("</ body> </ html > ");}); }}

Код выше делает следующее:

1. Включите проверку подлинности на основе файлов cookie (что, по-видимому, требуется для внешних поставщиков входа в систему) и укажите путь входа в систему как / login, поэтому любой запрос, требующий проверки подлинности, будет перенаправлен на этот путь.
2. Определите путь / логин, который отображает список настроенных типов аутентификации и позволяет пользователю выбрать один из них, щелкнув ссылку.
3. Когда пользователь нажимает на ссылку для типа аутентификации, он снова выполняет запрос к пути / login, но на этот раз передает тип аутентификации, запрошенный пользователем. Это вернет ответ на запрос, который вызывает указанный тип аутентификации.
4. Определите путь / logout для выхода пользователя из системы
5. Проверяет, прошел ли пользователь проверку подлинности, и если нет, выдаст ответ на запрос, который перенаправит пользователя на маршрут / login.
6. Наконец, если пользователь аутентифицирован, он выдаст имя пользователя и все утверждения, связанные с пользователем, например токен OAuth.

Думайте обо всем этом как о стандартном шаблонном коде, который шаблон приложения ASP.NET по умолчанию создаст для вас в той или иной форме после выпуска окончательных версий Visual Studio 2015 и ASP.NET 5. Для этого сообщения в блоге важна та часть, которая идет дальше, и это настройка аутентификации OAuth с GitHub.

Первым делом я зарегистрировал новое приложение в GitHub. Для URL-адреса обратного вызова приложения я указал URL-адрес моего веб-приложения (в моем случае http: // localhost: 35723) с помощью пути / signin-github. Вот скриншот приложения в GitHub, где вы можете увидеть все настройки, а также идентификатор клиента и секрет клиента:

Имея все это на месте, я добавляю код конфигурации для аутентификации GitHub в мой метод Configure (), где я ранее оставил комментарий:

app.UseOAuthAuthentication ("GitHub", options => {options.ClientId = "8de23516870d7145b84e"; options.ClientSecret = "0e3fd9808072907d1aa01df7e547ddbb6f6ec2fb ;; //github.com/login/oauth/authorize "; options.TokenEndpoint =" https://github.com/login/oauth/access_token ";});

Что код делает следующее:

1. Зарегистрируйте новый тип аутентификации под названием «GitHub», который использует новый универсальный обработчик аутентификации OAuth
2. Определяет идентификатор клиента и секрет, предоставленные GitHub
3. Определяет путь обратного вызова как / signin-github. Это должно совпадать с URL-адресом обратного вызова авторизации (т.е. URI перенаправления), который вы указали в GitHub
4. Определяет конечные точки авторизации и токена, как указано в документации GitHub

Со всем этим на месте мы можем запустить приложение. Первое, что вы заметите, это экран, на котором я выбираю тип аутентификации:

Нажмите на ссылку GitHub, которая отправит запрос на URL входа в систему с параметром authtype, указанным как «GitHub». Это вернет ответ на запрос, который вызовет общий обработчик OAuth, который, в свою очередь, будет обрабатывать рабочий процесс аутентификации OAuth 2.

Вы будете перенаправлены на веб-сайт GitHub, где вам необходимо войти в систему, если вы еще этого не сделали, а затем авторизовать приложение для доступа к вашей информации:

После того как вы нажмете «Авторизовать приложение», GitHub перенаправит обратно на URI перенаправления с временным кодом доступа, а обработчик OAuth, в свою очередь, вызовет конечную точку токена, чтобы запросить постоянный токен.

На этом этапе пользователь проходит аутентификацию, и токен будет добавлен в список утверждений для пользователя, который можно просмотреть, как только вы будете перенаправлены на корневой URL-адрес веб-сайта:

Заключение

В этом сообщении в блоге дается обзор общего процесса авторизации OAuth, а также о том, как настроить новый универсальный обработчик аутентификации OAuth в ASP.NET 5. В следующем сообщении я углублюсь в некоторые более сложные сценарии настройки.

PS: я публикую еженедельную рассылку для разработчиков ASP.NET под названием ASP.NET Weekly . Если вы хотите получать электронную почту каждую пятницу со всеми лучшими сообщениями в блогах, связанных с ASP.NET за предыдущую неделю, пожалуйста, Подписаться !

Похожие