Введение
Когда я говорил семье или друзьям, что я «работаю в identity», они часто предполагали, что это означает, что я работал в правительстве, в организации выдающей водительские права, или что я помогал людям разрешать мошенничество с кредитными картами.
Однако ни то, ни другое не было правдой. Ранее я работал в компании Auth0,, которая управляет цифровой идентификацией. (Сейчас я являюсь участником программы Auth0 Ambassadors и являюсь экспертом Google Developer по SPPI: Security, Privacy, Payments, and Identity — безопасность, конфиденциальность, платежи и идентификация.)
Цифровая идентификация
Цифровая идентификация это набор атрибутов, которые определяют отдельного пользователя в контексте функции, предоставляемой конкретным приложением.
Что это значит?
Скажем, вы управляете компанией по продаже обуви онлайн. Цифровой идентификацией пользователей вашего приложения может быть номер их кредитной карты, адрес доставки и история покупок. Их цифровая идентификация зависит от вашего приложения.
Это приводит нас к …
Аутентификация
В широком смысле, аутентификация относится к процессу проверки того, что пользователь является тем, кем он себя заявляет.
Как только система сможет установить это, мы приходим к …
Стандарты
Вы можете вспомнить, что я упомянул, что аутентификация основывается на четко определенных стандартах. Но откуда эти стандарты берутся?
Есть много разных стандартов и организаций, которые управляют работой Интернета. Два органа, которые представляют для нас особый интерес в контексте аутентификации и авторизации, — это Инженерная рабочая группа по Интернету (Internet Engineering Task Force — IETF) и Фонд OpenID (OpenID Foundation — OIDF).
IETF (Internet Engineering Task Force)
IETF — это большое открытое международное сообщество сетевых инженеров, операторов, поставщиков и исследователей, которые занимаются развитием интернет-архитектуры и бесперебойной работой интернета.
OIDF (OpenID Foundation)
OIDF — это некоммерческая международная организация людей и компаний, которые стремятся обеспечить, продвигать и защищать технологии OpenID.
Теперь, когда нам известны спецификации и кто их пишет, давайте вернемся к авторизации и поговорим о:
OAuth 2.0
OAuth 2.0 является одной из наиболее часто упоминаемых спецификаций, когда речь идет о сети, а также часто неправильно представленной или неправильно понятой.
OAuth не является спецификацией аутентификации. OAuth имеет дело с делегированной авторизацией. Помните, что аутентификация — это проверка личности пользователя. Авторизация касается предоставления или отказа в доступе к ресурсам. OAuth 2.0 предоставляет доступ к приложениям от имени пользователей.
Как было до OAuth
Чтобы понять цель OAuth, нам нужно вернуться назад во времени. OAuth 1.0 был создан в декабре 2007 года. До этого, если нам требовался доступ к сторонним ресурсам, это выглядело так:
Допустим, вы использовали приложение под названием HireMe123. HireMe123 хочет настроить событие календаря (например, встречу на собеседование) от вашего имени (пользователя). HireMe123 не имеет собственного календаря; поэтому нужно использовать другой сервис под названием MyCalApp для добавления событий.
После того, как вы вошли в HireMe123, HireMe123 запросит у вас ваши учетные данные для входа в MyCalApp. Вы должны ввести свое имя пользователя и пароль на сайте HireMe123.
Затем HireMe123 используя ваш логин получить доступ к API MyCalApp, и затем сможет создавать события календаря с использованием ваших учетных данных.
Совместное использование учетных данных — это плохо!
Этот подход основывался на совместном использовании личных учетных данных пользователя из одного приложения с совершенно другим приложением, и это не очень хорошо.
Так как, HireMe123 поставил на карту защиты вашей учетной записи MyCalApp гораздо меньше. Если HireMe123 не защитит ваши учетные данные MyCalApp надлежащим образом, и они в конечном итоге будут украдены или взломаны, кто-то сможет написать несколько неприятных статей в блоге, но HireMe123 как бы останется в стороне.
HireMe123 также получает слишком большой доступ к MyCalApp от вашего имени. HireMe123 получает все те же привелегии, что и вы, потому что он использовал ваши учетные данные для получения этого доступа. Это означает, что HireMe123 может читать все ваши события календаря, редактировать их, изменять настройки и т. д.
Registering a New User
For this, let’s create Models/RegisterModel.cs with the following properties. The user has to post data with this object to register.
public class RegisterModel
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string Username { get; set; }
public string Email { get; set; }
public string Password { get; set; }
}
In IUserService.cs, add a function definition to Register the user accepting a Register Model.
Task<string> RegisterAsync(RegisterModel model);
Go to the Concrete class, UserService to implement the Register Function.
public async Task<string> RegisterAsync(RegisterModel model)
{
var user = new ApplicationUser
{
UserName = model.Username,
Email = model.Email,
FirstName = model.FirstName,
LastName = model.LastName
};
var userWithSameEmail = await _userManager.FindByEmailAsync(model.Email);
if (userWithSameEmail == null)
{
var result = await _userManager.CreateAsync(user, model.Password);
if (result.Succeeded)
{
await _userManager.AddToRoleAsync(user, Authorization.default_role.ToString());
}
return $"User Registered with username {user.UserName}";
}
else
{
return $"Email {user.Email } is already registered.";
}
}
Let’s call this method from an API endpoint. Go to Controllers/UserController and add this set of code. Here we take in the Register model and pass it to user service, which returns a specific string message.
public async Task<ActionResult> RegisterAsync(RegisterModel model)
{
var result = await _userService.RegisterAsync(model);
return Ok(result);
}
Аутентификация на основе куки. Часть 1
ASP.NET Core имеет встроенную поддержку аутентификации на основе куки. Для этого в ASP.NET определен специальный компонент middleware, который сериализует данные пользователя в зашифрованные аутентификационные куки и передает их на сторону клиента. При получении запроса от клиента, в котором содержатся аутентификационные куки, происходит их валидация, десериализация и инициализация свойства User объекта HttpContext.
Рассмотрим на примере, как использовать простейшую аутентификацию в ASP.NET Core. Создадим новый проект Web Application (Model-View-Controller):
Вначале опеределим в проекте в папке Models модель пользователя – класс User :
Для взаимодействия с MS SQL Server через Entity Framework добавим в проект через Nuget пакет Microsoft.EntityFrameworkCore.SqlServer . А затем добавим в папку Models класс контекста данных UsersContext :
Далее в файле конфигурации appsettings.json определим настройки подключения к БД, которая будет хранить данные пользователей:
Изменим класс Startup для установки сервисов Entity Framework и подключения функицонала аутентификации и авторизации:
Здесь надо отметить два момента. Во-первых, в методе ConfigureServices() производится установка и настройка всех необходимых сервисов:
Для установки аутентификации с помощью куки в вызов services.AddAuthentication передается значение CookieAuthenticationDefaults.AuthenticationScheme . Далее с помощью метода AddCookie() настраивается аутентификация. По сути в этом методе производится конфигурация объекта CookieAuthenticationOptions , который описывает параметры аутентификации с помощью кук. В частности, в данном случае использовано одно свойство CookieAuthenticationOptions – LoginPath . Это свойство устанавливает относительный путь, по которому будет перенаправляться анонимный пользователь при доступе к ресурсам, для которых нужна аутентификация.
Второй момент – в методе Configure() внедряем в конвейер необходимые компоненты middleware:
Метод app.UseAuthentication() встраивает в конвейер компонент AuthenticationMiddleware, который управляет аутентификацией. Его вызов позволяет установить значение для свойства HttpContext.User . И метод app.UseAuthorization() встраивает в конвейер компонент AuthorizationMiddleware, который управляет авторизацией пользователей и разграничивает доступ к ресурсам.
В данном случае стоит различать понятия “аутентификация” и “авторизация”. Аутентификация отвечает на вопрос, кто пользователь. То есть посредством аутентификации мы идентифицируем пользователя, узнаем, кто он. А авторизация отвечает на вопрос, какие права в системе имеет пользователь, позволяет разграничить доступ к ресурсам приложения.
Представление
ASP.NET стремится к повышению производительности по сравнению с другими технологиями, основанными на сценариях (включая классический ASP), путем компиляции серверного кода при первом его использовании в один или несколько файлов DLL на веб-сервере . Эти DLL-файлы или сборки содержат Microsoft Intermediate Language (MSIL) для работы в среде CLR ; это обеспечивает повышение производительности по сравнению с чистыми скриптовыми языками и аналогично подходу, используемому в Python, и не отличается от JavaServer Pages . Эта компиляция происходит автоматически при первом запросе страницы (что означает, что разработчику не нужно выполнять отдельный этап компиляции для страниц).
Эта функция обеспечивает простоту разработки, предлагаемую языками сценариев, с преимуществами производительности скомпилированного двоичного файла. Однако компиляция может вызвать заметную, но короткую задержку для пользователя, когда новая отредактированная страница сначала запрашивается с веб-сервера, но не снова, если запрошенная страница не обновится дальше.
ASPX и другие файлы ресурсов размещаются на виртуальном хосте на сервере Internet Information Services (или других совместимых серверах ASP.NET; см. «Другие реализации» ниже). Когда клиент впервые запрашивает страницу, .NET Framework анализирует и компилирует файл (ы) в сборку .NET и отправляет ответ; последующие запросы обслуживаются из файлов DLL. По умолчанию ASP.NET компилирует весь сайт пакетами по 1000 файлов при первом запросе. Если задержка компиляции вызывает проблемы, размер пакета или стратегия компиляции могут быть изменены.
Разработчики также могут выбрать предварительную компиляцию своих файлов с выделенным кодом перед развертыванием с помощью Microsoft Visual Studio, что устраняет необходимость своевременной компиляции в производственной среде. Это также устраняет необходимость иметь исходный код на веб-сервере. Он также поддерживает предварительную компиляцию текста.
Open redirect attacks
Будь осторожен с редиректами! Следующий код очень опасен:
| 1 | Response.Redirect(Request.QueryString»Url»); |
Атакующий может добавить ссылку на свой сайт. А пользователь же, увидев, что URL начинается с хорошего сайта, может не рассмотреть адрес полностью (особенно если он длинный) и кликнуть ссылку, таким образом перейдя на вредоносный сайт с вашего, хорошего сайта. Эта уязвимость может использоваться, в частности, для фишинга. Пример фишинговой ссылки:
| 1 | http//www.goodwebsite.com/Redirect?url=http://www.badwebsite.com |
Этот вид атак касается и MVC. В следующем примере происходит проверка на то, является ли ссылка локальной:
|
1 |
privateActionResult RedirectToLocalPage(stringredirectUrl) { if(Url.IsLocalUrl(redirectUrl))returnRedirect(redirectUrl); // …. } |
Для защиты от этого типа атак можно использовать и вспомогательный метод LocalRedirect:
|
1 |
privateActionResult RedirectToLocalPage(stringredirectUrl) { returnLocalRedirect(redirectUrl); } |
В общем, старайся никогда не доверять полученным данным.
Создание ASP.NET проекта
Откройте Visual Studio Installer и нажмите «Изменить» на нужной среде разработки. Перед вами откроется список всех нагрузок. В категории Веб-разработка и облако нужно включить ASP.NET и разработка веб-приложений. После этого нажмите на кнопку Изменить в нижнем правом углу и дождитесь установки нагрузки.
Перейдите в Visual Studio и создайте новый проект, выбрав тип Веб-приложение ASP.NET (.NET Framework). Потом нужно выбрать необходимую модель приложения:
- Веб-формы — можно легко создавать динамические веб-сайты, используя сотни элементов управления и компонентов.
- MVC — эффективный, основанный на шаблонах способ создания динамических сайтов. Предоставляет полный контроль над разметкой для гибкой разработки.
- Веб-API — позволяет легко создавать HTTP службы для широкого диапазона клиентов. Идеальная платформа для сборки REST-приложений.
- Приложение SPA — одностраничное веб-приложение, которое загружает HTML-страницу и динамически обновляет её при взаимодействии с пользователем.
Выберете модель Веб-формы и завершите создание проекта.
Перенести существующий пользовательский веб-сервис на платформу .NET Core
Пользовательский веб-сервис, который был разработан на платформе .NET Framework и получает контекст без наследования базового класса Terrasoft.Web.Common.BaseService, можно перенести на платформу .NET Core. Для переноса необходимо выполнить адаптацию пользовательского веб-сервиса.
Свойство HttpContextAccessor класса Terrasoft.Web.Common.BaseService обеспечивает унифицированный доступ к контексту (HttpContext) в .NET Framework и .NET Core. Свойства UserConnection и AppConnection позволяют получить объект пользовательского подключения и объект подключения на уровне приложения. Это позволяет отказаться от использования свойства HttpContext.Current библиотеки System.Web.
Для веб-сервиса, который был разработан без наследования класса Terrasoft.Web.Common.BaseService реализованы следующие способы получения контекста:
-
Через IHttpContextAccessor, зарегистрированный в DI (ClassFactory).
Этот способ позволяет покрывать код тестами и отображает явные зависимости класса. Подробнее об использовании фабрики классов можно узнать из статьи Принцип замещения классов.
-
Через статическое свойство HttpContext.Current.
В исходный код с помощью директивы using необходимо добавить пространство имен Terrasoft.Web.Http.Abstractions. Статическое свойство HttpContext.Current реализует унифицированный доступ к HttpContext. Для адаптации кода веб-сервиса для платформы .NET Core замените пространство имен System.Web на Terrasoft.Web.Http.Abstractions.
Важно. В конфигурации запрещено использовать конкретную реализацию доступа к контексту запроса из .NET Framework (библиотека System.Web) или .NET Core (библиотека Microsoft.AspNetCore.Http)
Вызвать пользовательский веб-сервис
Пользовательский веб-сервис можно вызвать из браузера и из front-end части.
Вызвать пользовательский веб-сервис из браузера
Вызвать из браузера пользовательский веб-сервис с аутентификацией на основе cookies
Чтобы вызвать из браузера пользовательский веб-сервис с аутентификацией на основе cookies для платформы .NET Framework:
- Для получения аутентификационных cookie используйте системный веб-сервис AuthService.svc.
-
Для вызова пользовательского веб-сервиса используйте строку запроса:
Для платформы .NET Core процедура вызова пользовательского веб-сервиса с аутентификацией на основе cookies аналогична. Различие — не нужно использовать приставку /0.
Вызвать из браузера пользовательский веб-сервис с анонимной аутентификацией
Чтобы вызвать из браузера пользовательский веб-сервис с анонимной аутентификацией для платформы .NET Framework, используйте строку запроса:
Для платформы .NET Core процедура вызова пользовательского веб-сервиса с анонимной аутентификацией аналогична. Различие — не нужно использовать приставку /0.
Вызвать пользовательский веб-сервис из front-end части
- В модуль страницы, из которой вызывается веб-сервис, в качестве зависимости подключите модуль ServiceHelper. Этот модуль предоставляет удобный интерфейс для выполнения запросов к серверу через провайдер запросов Terrasoft.AjaxProvider, реализованный в клиентском ядре.
-
Вызовите пользовательский веб-сервис из модуля ServiceHelper.
Способы вызова пользовательского веб-сервиса:
- Вызовите метод callService(serviceName, serviceMethodName, callback, serviceData, scope).
-
Вызовите метод callService(config), где config — конфигурационный объект со свойствами:
serviceName — имя пользовательского веб-сервиса.
methodName — имя вызываемого метода пользовательского сервиса.
callback — функция обратного вызова, в которой выполняется обработка ответа от веб-сервиса.
data — объект с проинициализированными входящими параметрами для метода веб-сервиса.
scope — контекст выполнения запроса.
Важно. Модуль ServiceHelper работает только с POST-запросами
Поэтому к методам пользовательского веб-сервиса необходимо добавить атрибут с параметром Method = «POST».
Использование авторизации на основе политик в ASP.NET Core
Модель безопасности на основе политик разъединяет авторизацию и логику приложения и предоставляет гибкую, повторно используемую и расширяемую модель безопасности в ASP.NET Core. Модель безопасности на основе политик основана на трех основных концепциях. К ним относятся политики, утверждения и обработчики. Политика состоит из нескольких утверждений. Утверждения, в свою очередь, содержат параметры данных для проверки личности пользователя. Наконец, обработчик используется для определения, имеет ли пользователь доступ к определенному ресурсу. Мы обсудим каждый из них более подробно в этом разделе — начнем с политики.
По сути, политика состоит из одного или нескольких утверждений и обычно регистрируется при запуске приложения в методе файла . Чтобы применить политики в ваших контроллерах или методах действий, вы можете воспользоваться атрибутом или фильтром .
Вы можете создать экземпляр политики, используя класс , как показано в приведенном ниже фрагменте кода. Вы можете указать имена ролей, используя метод .
Кроме того, вы можете создать экземпляр политики в методе , как показано ниже.
Summary
In this Detailed guide we have covered the basics of JWT, Registering Users, Seeding Databases, Entity Framework Core – Code First, Generating JWTs, Securing Endpoint based on Roles, Adding Roles to Users.
In the next article, we will discuss Refresh Tokens, which makes our APIs even more secure. The article is published. You can check it here to learn more about Refresh tokens and it’s implementation in ASP.NET Core APIs here.
Do you have any other queries suggestions for me? Feel free to leave them below in the comments section. Happy Coding
If you found this article helpful,
Buy me a coffee
Source Code
The Completed Source code is available in my Github.Do Follow me on GitHub as well.
Get The Code
Добавление Scaffold Identity
Добавим код страниц регистрации и логинирования в наше приложение. Для этого воспользуемся шаблоном Scaffold Identity, для выборочного добавления исходного кода, содержащегося в Identity Razor библиотеке классов (RCL).
- Правой кнопкой мыши щелкнуть на название проекта (в нашем случае BSAdminPanel).
- В контекстном меню выбрать Добавить->Создать шаблонный элемент.
- В диалоговом окне, слева, выбрать Удостоверение
- В диалоге Добавить Удостоверение отмечаем два файла для переопределения: Account\Login и Account\Register
- Класс контекста данных выбрать который уже есть в приложении
- Выбор страницы макета оставьте нетронутым. Макет сформируется автоматически.
После cформирования всей структуры папок в приложении два файла _LoginPartial.cshtml. Структура формируется на новый файл, который находится в папке «/Pages/Shared/_LoginPartial.cshtml», его оставляем. А в папке «/Areas/Identity/Pages/Shared/_LoginPartial.cshtml» можно удалить. Структура строится по типу шаблона для Razor Pages.
Токены доступа
Токены доступа (Access Token) используются для предоставления доступа к ресурсам. С токеном доступа, выданным сервером авторизации MyCalApp, HireMe123 может получить доступ к API MyCalApp.
В отличие от токенов ID, которые OIDC объявляет как веб-токены JSON, токены доступа не имеют определенного формата. Они не должны быть (и не обязательно) JWT. Однако во многих решениях для идентификации используются JWT как маркеры доступа, поскольку есть готовый формат и он обеспечивает хорошую проверку.
В итоге HireMe123 получает два токена от сервера авторизации MyCalApp: токен идентификации (Token ID) (если проверка пользователя прошла успешна) и токен доступа (Access Token) для доступа к ресурсам конечному пользователю.
Токены доступа прозрачны для клиента
Токены доступа предназначены для API ресурса, и важно, чтобы они были прозрачны для клиента. Зачем?. Токены доступа могут измениться в любое время
У них должно быть короткое время истечения, поэтому пользователь может часто получать новые. Они также могут быть переизданы для доступа к различным API или использования разных разрешений. Клиентское приложение никогда не должно содержать код, который опирается на содержимое токена доступа. Код, который делает это, был бы хрупким и почти гарантированно сломался
Токены доступа могут измениться в любое время. У них должно быть короткое время истечения, поэтому пользователь может часто получать новые. Они также могут быть переизданы для доступа к различным API или использования разных разрешений. Клиентское приложение никогда не должно содержать код, который опирается на содержимое токена доступа. Код, который делает это, был бы хрупким и почти гарантированно сломался.
Требования
Под покровом используются методы авторизации на основе ролей и утверждений, основанные на требованиях, обработчике и политике. В этом и последующих разделах будет рассмотрен каждый из них.
Требование включает в себя набор параметров данных. Эти параметры данных используются политикой для оценки личности пользователя. Чтобы создать требование, вам нужно создать класс, который реализует интерфейс IAuthorizationRequirement. Следующий фрагмент кода иллюстрирует требование для политики MinimumExp — вы зарегистрируете эту политику через некоторое время.
|
public class MinimumExpRequirement : IAuthorizationRequirement { public int MinimumExp { get; set; } public MinimumExpRequirement(int experience) { MinimumExp = experience; } } |
Аутентификация при входе
После проверки работы приложения, приступаем к организации проверки подлинности пользователей при входе в панель управления. В файл /Areas/AdminPanel/_Imports.razor добавим @attribute для запрета доступа к страницам папки без идентификации пользователя. Теперь при запуске приложения формируется страница с интерфейсом доступа и навигационным меню панели управления, но вместо содержания служебная надпись «Not authorized». В приложении ещё нет механизма, отсеивающего не авторизированный доступ к закрытым веб страницам.
По умолчанию файл App.razor, входной компонент приложения ответственный за маршрутизацию, не имеет компонента предназначенного для обработки неавторизированного доступа. Запрет к закрытым страницам с атрибутом Authorize стандартно осуществляет добавленный при создании приложения встроенный пользовательский интерфейс Microsoft.AspNetCore.Identity.UI.
Теперь при запуске приложения будет выходить надпись “Вход воспрещен”. Но главная страница сайта всё равно создаётся на основе файла _Host.cshtml с навигационным администраторским меню, со всеми его файлами css и javascript функциями. Теперь необходимо создать компонент, который будет автоматически перенаправлять неавторизированных пользователей на страницу логинирования или аутентификации, без участия главного файла панели администратора _Host.cshtml.
Компонент для обработки попыток входа неавторизированных пользователей может иметь любое имя. Назовём его NotAuthorizedHandler.razor и добавим в него поддержку класса NavigationManager, служащий для управления URI навигацией. Код перенаправления разместим в теле самого первого метода жизненного цикла компонента Blazor Server SetParametersAsync(…). Расположим этот компонент в корневой папке Shared.
Теперь при загрузке приложения будет появляться специальная страница аутентификации. Для входа в авторизированную зону необходимо зарегистрироваться и затем успешно работать в панели администратора. Для тестирования регистраций и авторизаций можно понизить уровень строгости проверки пароля. Для этого в файле Startup.cs, в методе ConfigureServices(IServiceCollection services) изменить опции идентификации.
При первой регистрации на сайте выйдет страница с такой ошибкой:A database operation failed while proccesing the requestApplying existing migrations for ApplicationDbContext may resolve this issue
( Ошибка операции с базой данных при обработке запроса
Принятие существующую миграцию для ApplicationDbContext может решить эту проблему.)
Это означает что база данных еще не создана, необходимо нажать на кнопку Apply Migrations и запустить процесс создания базы данных для возможности регистрации пользователей. Затем обновить страницу и, если регистрация была успешной, откроется администраторская панель управления. Создание приложения Blazor Server с авторизацией функционально готово.
Регистрация обработчика
Вы должны зарегистрировать обработчики в коллекции сервисов. Чтобы зарегистрировать обработчик, созданный ранее в этой статье, вы должны написать следующий код в методе класса .
Обратите внимание на использование метода в методе , приведенном выше. При работе с внедрением зависимостей в ASP.NET Core вы можете указать время жизни службы, используя методы , или
В этом примере используется время жизни синглтона. При использовании этого типа срока службы службы экземпляр службы будет создан при первом запросе. Последующие запросы к службе будут повторно использовать тот же экземпляр.
Testing the Secure Web API
In order to ensure that all works as expected, run the application, point your browser to https://localhost:5001/swagger, and test the GET action on the endpoint. You should get the list of term definitions as before.
Testing unauthorized accesses
Now, try to add a new item to the glossary by using the POST action on the endpoint as shown in the following picture:
This time you should get a HTTP status code, as shown below:
This means that your endpoint is protected: only authorized users can add a new definition to the list. So, in order to add a new item to the glossary, you need to get an access token from Auth0 and make a request to the API endpoint using the Bearer Authorization scheme.
Testing authorized accesses
However, before going ahead, you need a way to provide your access token to the interactive web API documentation. To achieve this goal, edit the file and apply the changes shown in the following code snippet to the method:
You added a few additional configuration options to your API’s Swagger instance. In particular, you defined a security schema and added it to the generated documentation as a security requirement.
Now, restart your ASP.NET Web API and take a look at the web page shown at the address https://localhost:5001/swagger:
You see the new Authorize button and the lock icon on each action. You can configure Swagger to get a more accurate UI, but this topic is out of the scope of this article. Please check out .
At this point, let’s get the access token from Auth0. The simplest way is to access again, select the API that you created before and select the Test tab. In this section, you can get a temporary token to test your Web API by clicking the Copy Token icon as shown in the following picture:
Now, head back to your browser and click the Authorize button. A window dialog opens, as shown in the following picture:
Paste the token you copied from the Auth0 Dashboard into the text box and click Authorize.
With this step, you have configured the interactive documentation to add the Authorization header to each HTTP request. That header’s value will be the access token in the form of a bearer token.
If you try to add a new glossary term through the POST action, you should get a successful HTTP status code as before securing the API. The following picture shows an example of such a response:
Now your Web API is ready to be securely consumed by clients.
