Введение в OpenID Connect в ASP.NET Core

Этот пост является следующим в серии постов об аутентификации в ASP.NET Core. В предыдущем посте мы показали, как вы можете использовать протокол OAuth 2.0, чтобы обеспечить функциональность «Войти через Facebook» на свой веб-сайт.

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

Open ID Connect добавляет дополнительный уровень поверх протокола OAuth, который решает ряд этих проблем. В этом посте мы рассмотрим различия между OpenID Connect и OAuth, как использовать Open ID Connect в вашем приложении ASP.NET Core и как зарегистрировать ваше приложение у поставщика OpenID Connect (в данном случае Google).

Что такое OpenID Connect?

OpenID Connect — это простой уровень идентификации, который работает поверх OAuth 2.0. Он использует тот же базовый протокол REST, но обеспечивает согласованность и дополнительную безопасность поверх протокола OAuth.

Также стоит отметить, что протокол OpenID Connect сильно отличается от протокола OpenID. Последний представлял собой протокол на основе XML, который следует тем же подходам и целям, что и OpenID Connect, но менее удобен для разработчиков.

Зачем использовать его вместо OAuth 2.0?

В моем недавнем посте я показал, как вы можете использовать OAuth 2.0 для входа через Facebook в ваше приложение ASP.NET Core. Вы можете подумать: «Зачем мне еще один уровень идентификации, OAuth 2.0 работает отлично?». К сожалению, есть несколько проблем с OAuth 2.0 как с механизмом аутентификации.

Прежде всего, OAuth 2.0 — это протокол авторизации , а не аутентификации . Весь его дизайн основан на предоставлении доступа к некоторому защищенному ресурсу (например, профилю Facebook или фотографиям) третьей стороне (например, вашему приложению ASP.NET Core).

Когда вы «Войти через Facebook», мы выполняем псевдо-аутентификацию, доказывая, что вы можете предоставить доступ к защищенному ресурсу. Nat Sakimura блестяще объясняет это в своем блоге , когда говорит, что использование OAuth для аутентификации похоже на предоставление кому-то служебного ключа от вашего дома. Имея возможность предоставить ключ от вашего дома, веб-сайт может предположить, что вы являетесь данным лицом, но на самом деле вы не были должным образом аутентифицированы как таковые. Кроме того, на этом сайте теперь есть ключ от вашего дома! Этот последний момент является одной из основных проблем безопасности OAuth 2.0 — существуют различные меры по смягчению последствий, но они не решают фундаментальную проблему.

OpenID Connect решает эту проблему в OAuth 2.0, по сути, предоставляя ключ только к шкафчику, который содержит ваше удостоверение личности. Вместо того, чтобы предоставлять доступ ко всему вашему дому, шкафчик — это все, до чего вы можете добраться.

Во-вторых, требования к реализации OAuth 2.0 очень свободны. Спецификация устанавливает ряд технических деталей, но существует множество тонко различающихся реализаций у разных поставщиков. Просто взгляните на количество поставщиков, доступных в репозитории AspNet.Security.OAuth.Providers , чтобы получить представление об этом. Каждый из этих провайдеров требует определенной настройки, помимо указания URL-адресов и секретов. Каждый из них возвращает данные в другом формате и должен иметь проанализированные возвращенные утверждения. OpenID Connect предъявляет гораздо более жесткие требования, что обеспечивает большую совместимость.

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

Там, где он доступен, действительно кажется, что лучший совет — всегда выбирать OpenID Connect вместо простого OAuth. Действительно, Доминик Байер, известный Identity Server (среди прочего), говорит примерно следующее в своем блоге :

... мы всегда рассматривали OpenID Connect как «надстройку» OAuth 2.0 и всегда рекомендовали не использовать OAuth без частей OIDC.

Поток

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

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

Под прикрытием есть некоторые тонкие различия в данных, отправляемых туда и обратно между вашим приложением и серверами авторизации, но они в значительной степени скрыты от вас как от разработчика-потребителя. Параметр scopeимеет дополнительное openidзначение, указывающее, что это запрос OpenID Connect, а ответ ACCESS_CODE содержит , id_tokenкоторый используется для проверки целостности данных. Наконец, запрос к серверу ресурсов на получение любых дополнительных утверждений возвращает утверждения стандартизированным способом с использованием предустановленных ключей утверждений, таких как given_nameи family_name. emailЭто избавляет вас от связанного с реализацией сопоставления утверждений, которое необходимо для OAuth 2.0.

Добавление OpenID Connect в ваше приложение

Надеюсь, вы уже убедились в преимуществах OpenID Connect, поэтому давайте рассмотрим его добавление в проект ASP.NET Core.

Как и прежде, я предполагаю, что у вас есть проект ASP.NET Core, созданный с использованием стандартного шаблона MVC «Индивидуальные учетные записи пользователей».

Первым делом нужно добавить пакет OpenID Connect в ваш project.json:

{
  "dependencies": {
    "Microsoft.AspNetCore.Authentication.OpenIdConnect": "1.0.0"
  }
}

и настройте промежуточное ПО в своем Startup.Configureметоде:

public void Configure(IApplicationBuilder app, IHostingEnvironment env)  
{

    app.UseStaticFiles();

    app.UseIdentity();

    app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions
        {
            ClientId = Configuration["ClientId"],
            ClientSecret = Configuration["ClientSecret"],
            Authority = Configuration["Authority"],
            ResponseType = OpenIdConnectResponseType.Code,
            GetClaimsFromUserInfoEndpoint = true
        });

    app.UseMvc(routes =>
    {
        routes.MapRoute(
            name: "default",
            template: "{controller=Home}/{action=Index}/{id?}");
    });
}

Мы создали новый объект OpenIdConnectOptions, добавили ClientIdи ClientSecretполучили при регистрации нашего приложения у провайдера OpenID Connect (подробнее об этом ниже) и указали, Authorityчто указывает фактического провайдера OpenID Connect, который мы используем. Как обычно, мы подгрузили эти значения из конфигурации, которые при разработке должны быть сохранены в менеджере пользовательских секретов .

В оставшейся части статьи я буду предполагать, что вы настраиваете Google в качестве своего провайдера, поэтому в этом случае значение «Полномочия» будет равно "https://accounts.google.com". С установленным промежуточным программным обеспечением у нас есть все необходимое для базовой реализации OpenID Connect «Вход через Google».

Когда пользователь попадет на страницу входа, он увидит возможность входа с помощью «OpenIdConnect». Очевидно, что в производстве вы, вероятно, захотите обновить его до чего-то более удобного для пользователя!

Затем пользователю предоставляется обычный экран входа в Google (если он еще не вошел в систему) и предлагается авторизовать ваше приложение ASP.NET:

Нажатие «Разрешить» перенаправит пользователя обратно в ваше приложение ASP.NET с кодом AUTH_CODE. Затем ваше приложение может связываться через обратный канал с Google для аутентификации пользователя и входа в ваше приложение.

Регистрация вашего приложения в Google

Как и при настройке Facebook в качестве поставщика OAuth 2.0 для нашего приложения, нам необходимо зарегистрировать наше приложение в Google, прежде чем мы сможем использовать OpenID Connect.

Первый шаг — посетить http://console.developers.google.com и зарегистрироваться в качестве разработчика. После входа в систему и настройки вы можете зарегистрировать свое приложение. Нажмите «Проект» и «Создать проект» в верхнем меню.

Вам нужно будет дать вашему приложению имя и согласиться с условиями:

Теперь вам нужно сгенерировать некоторые учетные данные для вашего приложения, чтобы мы могли получить необходимые CLIENT_ID и CLIENT_SECRET. Нажмите «Учетные данные» на левой панели и, если необходимо, выберите свой проект. Затем вы можете создать учетные данные для своего проекта. Для веб-сайта ASP.NET Core вам потребуется выбрать параметр идентификатора клиента OAuth:

Затем выберите веб-приложение из доступных вариантов, укажите имя и URI перенаправления. Этот URI будет доменом, в котором будет развернуто ваше приложение (в моем случае http://localhost:5000), за которым следует /signin-oidc(по умолчанию)

При нажатии кнопки «Создать» вам будут представлены ваш CLIENT_ID и CLIENT_SECRET. Просто сохраните их в своих пользовательских секретах, и все готово!

Резюме

В этом посте мы увидели, как добавить вход с помощью OpenID Connect в приложение ASP.NET Core. Мы описали отличия протокола OpenID Connect от OAuth 2.0 и подчеркнули преимущества безопасности и разработки по сравнению с обычным OAuth. Наконец, мы показали, как зарегистрировать ваше приложение в Google, чтобы получить ваш идентификатор клиента и секрет.