Как проверяется токен доступа для доступа к защищенным ресурсам в механизме на основе токенов?

Вы можете контролировать, какая информация помещается в токен. Посмотрите на класс SimpleAuthorizationServerProvider в статье:

var identity = new ClaimsIdentity(context.Options.AuthenticationType);
identity.AddClaim(new Claim("sub", context.UserName));
identity.AddClaim(new Claim("role", "user"));

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

Это взято из статьи:

Второй метод «GrantResourceOwnerCredentials» отвечает за проверку имени пользователя и пароля, отправленных на конечную точку токена сервера авторизации, поэтому мы будем использовать класс «AuthRepository», который мы создали ранее, и вызовем метод «FindUser», чтобы проверить, являются ли имя пользователя и пароль действительный.

Если учетные данные действительны, мы создадим класс «ClaimsIdentity» и передадим ему тип аутентификации, в нашем случае «токен носителя», затем мы добавим два утверждения («под», «роль»), и они будут включены в подписанном токене. Вы можете добавлять сюда различные претензии, но размер токена обязательно увеличится.

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

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

Если вы позаботитесь о том, как вы передаете токены, то есть в заголовке авторизации по вызову https, тогда вы максимально защищены, и заголовки будут зашифрованы. Суть здесь в том, чтобы никогда не выполнять подобные вызовы через базовый http.

Автор статьи, на которую вы ссылаетесь, является уважаемым авторитетом в этой конкретной области и в настоящее время Microsoft MVP, и вы в основном в хороших руках. Продолжайте читать его статьи, но обращайте внимание на детали.

----------- Пояснение относительно формата JWT --------------

да, токен JWT также будет содержать информацию, связанную с датой выпуска и сроком действия. У меня есть собственная статья на эту тему: https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/

Посмотрите на вызовы, которые создают токен, и посмотрите на информацию, возвращаемую на снимках экрана.

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

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

Когда дело доходит до OAuth2, нужно понимать ряд концепций, это требует небольшого исследования и практики.

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

Я предлагаю начать с малого, шаг за шагом, использовать Postman для построения ваших звонков и понимания того, что происходит. Когда у вас есть эти знания, вам будет намного легче двигаться вперед. Мне потребовалось около 6 недель, чтобы осознать все концепции и заставить что-то работать с первого раза, но теперь это занимает максимум пару часов. Удачи

Приложению не нужно хранить токен доступа на стороне сервера, оно будет считывать пользователя только из переданного токена.

Когда запрос попадает на сервер аутентификации, который подключен к конвейеру Owin в методе ConfigureOAuth(), токен заголовка HTTP расшифровывается, и пользовательские данные из токена передаются текущему пользователю контекста.

Это одна из вещей, которая меня давно беспокоила

Я не уверен, что понимаю, почему вы привели пример для 2 приложений, но механизм токена на самом деле прост, но это своего рода черный ящик, когда вы используете owin и identity

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

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

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

просто забавное примечание: даже если вы полностью изменили БД, токен все равно будет действителен с идентификатором пользователя, которого даже не существует в вашей новой БД! но, конечно, идентификация автоматически аннулирует этот токен, когда он сравнивается с securityStamp