ᅠ

Обзор статьи "Security and Privacy of Social Logins"

На эту работу наткнулся ещё в начале прошлого года и с тех пор все хотел ей поделиться. На самом деле, это даже Master's Thesis, а не просто статья, но написано хорошо.

▫️После вводной части - тоже весьма интересной - во 2 главе кратко и емко, объясняются основные концепции OAuth 2.0 и OIDC.
Хочу отдельно отметить акценты на некоторых понятиях и принципиальных моментах, которые позволяют при внимательном прочтении корректно понять суть и назначение данных стандартов. Еще импонирует, что автор выделяет и использует термины вида "Authentication request" и "Token request", как они названы в спецификации OIDC.
Далее в этой же главе кратко описываются базовые концепции работы JS в браузере, в основном применительно к Window-интерфейсу , упоминается про Same Origin Policy и про то, какие механизмы для cross-origin обмена данными в браузерах существуют (CORS, PostMessage API, Channel Messaging API).
▫️3 глава посвящена обзору "Single Sign-On Protocols in the Wild" - реальным имплементациям, которые мы встречаем в повседневной жизни. Здесь автор рассматривает три IdP: Apple, Google, Facebook и разбирает их реализации на момент 2020 года.
Что здесь примечательного:
- Apple в данном случае также использует именно OIDC, не применяя часть delegated access от OAuth2.0, access token у Apple "is reserved for future use". Хороший пример, как остаться в целом standard-compliant, но при этом не делать себе лишнюю функциональность, которая не нужна
- У тех же Apple есть ещё один интересный подход, где они не разглашают приложениям реальный email пользователя, а выдают анонимный адрес, который служит некоей проксей
- У Google в одном из протоколов использовались iframe, в том числе и для consent screen. Чтобы снизить риски возможной clickjacking, JS-SDK был вынужден проверять через API браузера, что фрейм действительно виден на экране
▫️В 4 главе разбирается вопрос безопасности при использовании PostMessage. Автор подмечает, что:

In fact, the OWASP HTML5 Security Cheat Sheet considers web messaging as a top security threat in HTML5 and requires developers to implement non-trivial security checks. Thus, the responsibility of implementing the postMessage API in a secure manner is outsourced to developers.

Начало главы может кому-то показаться неинтересным, поскольку там разбираются в основном методы защиты на фронтенде, однако далее приводятся результаты исследования реальных имплементаций из списка The Moz Top 500 Websites, которые показывают достаточно большое количество найденных авторами уязвимостей, связанных с использованием PostMessage, приводящих в том числе к Account takeover. И здесь отмечу, что это уже не только уязвимости в клиентской части, но скорее design flaws - недостатки проектирования.
Также из интересного подмечу упоминание:

We also noticed that SPs are using a single backend implementation – which reduces implementation efforts – for multiple IdPs. For instance, all IdPs redirect to the same redirectionEndp, such that the context switch must only be implemented once.

Это правда, тоже встречал приложения, которые используют OAuth2.0/OIDC с несколькими Authorization servers, в них делался единообразный подход для обработки ответа с authorization_code.
▫️Пятая глава вышла немного сборной солянкой. Сначала автор рассказывает про XS-Leaks, на примерах объясняя, как это может быть использовано для получения некоторой информации о пользователе.
Далее отдельно упоминается Login CSRF, а после - довольно интересное место - описывается автоматический вход пользователя в приложения через различные IdP, если ранее уже этот пользователь давал согласие (consent) данному приложению. И автор корректно подмечает, что здесь в угоду User Experience жертвуется часть безопасности и приватности.

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

#paper #oauth

Зачем и когда нужны OAuth 2.0 и OIDC

Хоть упоминания OAuth 2.0/OIDC встречаются очень часто, надо не забывать, что это не универсальное решение всех ваших проблем, а протоколы/стандарты, которые используются для вполне конкретных и понятных случаев.
И здесь интереснее сказать не "что такое", а "зачем такое", зачем они нужны.

🟢 OAuth 2.0 задумывался для того, чтобы пользователь мог делегировать доступ какому-либо приложению (Client, Service Provider) к ресурсам от своего лица в рамках неких ограничений или же приложение могло получить ограниченный доступ от своего же лица.
При всем этом OAuth не предполагает штатной возможности для приложения получить Identity (личность) пользователя или же попросту узнать, а кто он такой, он позволяет только предоставить доступ. Естественно без OIDC все попросту брали полученный access token и обращались в условную ручку /me за получением данных о пользователе.

🟢  OIDC как раз является определенной надстройкой над OAuth 2.0, расширяющей его возможности. Его суть - позволить приложению узнать, а кто же в него входит, то есть получить ту самую Identity аутентифицируемого пользователя. Здесь Authorization Server называют OpeinID Provider (OP). Мы как приложение доверяем OP для получения личности пользователя и как бы полагаемся на него ("rely on") - приложение в терминах OIDC так и называют - "Relying Party (RP)". Спецификация предполагает, что OP становится не только Authorization server, но и Resource server, но только для данных о пользователе. И предполагается 2 способа для передачи данных о пользователе от OP к RP:
- Специальный токен в формате JWT - идентификационный ID token, который выпускается для использования именно самим приложением Client (одно из самых важных его отличий)
- Стандартный эндпоинт userinfo, позволяющих также получить набор данных о пользователе

На эту тему есть интересная статья, на которую часто ссылаюсь: https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/
Да, в ней есть большая порция рекламы их продуктов, но если ее отбросить, тезисы там изложены корректные.

Дерево решений, которое там предлагается, на мой взгляд, покрывает не все случаи, однако далее как раз упоминается и про примеры использования OAuth2.0/OIDC для First-party в больших системах, что может иметь смысл, поскольку позволяет ограничить область применения полученного токена рамками одного из приложений.

Также моё почтение за выделение того, что OAuth2.0/OIDC - это не всегда просто и легко, и подводные камни там имеются, и известного факта "scopes are not permissions"

#article #oauth

Microservices Security Cheat Sheet от OWASP

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

Что пишут интересного:

👍 Про Edge-level авторизацию как дополнение к, а не замену основной точке авторизации

👍 Кратко упоминают про типовые подходы к Service-level авторизации:
- Децентрализованный, где Policy Decision Point (PDP) и Policy Enforcement Point (PEP) реализуются в каждом сервисе
- Централизованный, где
сервисы имеют свою PEP, но обращаются к единой PDP для получения решения согласно политикам доступа
- Централизованный со встроенной PDP, где в каждом сервисе держится своя PDP (например, как sidecar), которая может асинхронно подпулливать обновления политик из единого источника и хранит именно их, а решения принимает "на ходу" на их основе

👍 Identity Propagation - интересная тема, про которую нечасто говорят. Здесь хотя бы упоминают примеры решения такой задачи

👍 Два базовых подхода к Service-to-Service аутентификации: mTLS и токены.
Причем здорово упоминают, что в зависимости от критичности запроса (на самом деле в целом от требований к ИБ) токен можно делать как stateful, так и stateless, то есть позволяющий провести оффлайн-проверку. А также что перед принятием решения об аутентификации по сертификатам очень полезно подумать о PKI и как во всех местах с этими сертификатами работать

#security #iam_general

Организация KuppingerCole ежегодно публикует результаты исследований, где оценивает участников рынка в разных областях Identity & Security.
В 2023 году был также опубликован и анализ для рынка Access Management.

Отмечается, что

The term “Access Management” refers to the group of capabilities targeted at
supporting access management requirements of organizations ranging from authentication,
authorization, single sign-on, and identity federation traditionally found within Web Access
Management (WAM) & Identity Federation solutions.

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

В общем зачёте лидерами выделяют (в алфавитном порядке):
• CyberArk
• ForgeRock
• IBM
• Microsoft
• Okta
• One Identity
• OpenText
• Oracle
• Ping Identity
• Thales

Также есть и прочие распределения участников исследования и сводка по каждому из них.

#paper #iam_general

Кроме этого, также есть интересный отчет и по направлению API Security and Management

#paper #api

Типы JWT: JWS и JWE

JSON Web Token (JWT), произносится, кстати, как "jot" - это популярный формат представления информации для её передачи.
В нем информация заключается в т. н. claims и помещается в JSON-объект, который так и назвали - JWT Claims Set.
На самом деле, JWT никак напрямую не связан с аутентификацией или авторизацией и, хоть и часто там встречается, но может применяться и в других контекстах.

Нюанс в том, что сам по себе физически JWT просто так никогда не существует. Он всегда представлен в одном из двух видов: JWS или JWE.

JWS или же JSON Web Signature - как раз одна из таких структур. Причём самая распространенная: чаще всего, когда мы говорим "JWT", то имеем в виду именно её.
JWS состоит из 3 частей, разделённых точками:
- JOSE Header (header)
- payload
- signature*

[header].[payload].[signature]

JWS - это в первую очередь распространённый и общепринятый способ обеспечить целостность (integrity) информации при ее передаче в том числе через участки, к которым нет доверия. За счёт наличия механизма подписи мы можем проверить, что содержимое payload было подписано с помощью необходимого ключа и не изменено где-то "по пути".
JWS никак не шифрует и не скрывает содержимое header и payload.
*Технически возможно также использование JWT и без механизма подписания. Как говорит нам п. 6 RFC 7519, такой JWT будет называться "unsecured", и для него значение параметра "alg" из header будет равняться "none". С этим, кстати, связана одна из широкоизвестных атак на JWT: в случае если принимающая сторона принимает значения алгоритма из параметра "alg" и не валидирует его явно по разрешенному списку, злоумышленник может изменить его значение в header на "none", тем самым обойдя проверку подписи в некоторых имплементациях.

JSON Web Encryption (JWE) - еще один способ для физического представления JWT. Есть два вида сериализации JWE: Compact Serialization и JSON Serialization. Речь будем вести про Compact-случай.
JWE в этом случае состоит из 5 частей, соединенных точками:
- JOSE Header (header)
- Encryption key (Content encryption key, CEK)
- Initialization Vector
- Ciphertext (payload)
- Authentication Tag

[header].[Encryption-key].[Initialization-Vector].[payload].[Authentication-Tag]

Применение JWE может быть полезно, когда требуется обеспечить не только целостность информации, но и ее конфиденциальность.
В этом случае мы можем зашифровать данные с помощью алгоритма и ключа (чаще всего, публичного), и расшифровать их сможет только та сторона, которая также владеет ключом (при ассиметричном шифровании - приватным).
При этом для JWE часто может использоваться так называемый "nested JWT": в качестве значения "payload" мы можем зашифровать уже подписанный JWS. В таком случае после расшифровки будет получен еще один JWT.
В реальной жизни JWE можно встретить в кейсах, когда требуется шифрование ID Token. Об этом говорит и спецификация OIDC:

ID Tokens MUST be signed using JWS and optionally both signed and then encrypted using JWS and JWE respectively, thereby providing authentication, integrity, non-repudiation, and optionally, confidentiality, per Section 16.14. If the ID Token is encrypted, it MUST be signed then encrypted, with the result being a Nested JWT.

Здесь приложение как Client предоставляет Authorization server (IAM-решению) свой public key путем явной передачи или через предоставление JWKS URI. Далее IAM при выпуске id-токена для приложения может зашифровать его с использованием указанного ключа, а приложение как владелец приватного ключа, получив токен, сможет выполнить дешифрование и извлечь полезную нагрузку.

#jwt

Must-read две части классической статьи про проблемы использования JWT как сессионного токена

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

В публикациях много полезных мыслей, но отдельно я, пожалуй, выделю еще следующую важную цитату из самого начала:

A lot of people mistakenly try to compare "cookies vs. JWT". This comparison makes no sense at all, and it's comparing apples to oranges - cookies are a storage mechanism, whereas JWT tokens are cryptographically signed tokens.

• Stop using JWT for sessions
• Stop using JWT for sessions, part 2: Why your solution doesn't work

#iam_general #jwt #article

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

upd. пишут, что видеосвязь ни при чем

https://habr.com/ru/articles/791074/

Про повторную утечку access token через Web Cache Deception в chat.openai.com

В феврале прошлого года в chat.openai[.]com была найдена уязвимость web cache deception. Исследователь обнаружил, что в приложении есть эндпоинт /api/auth/session, который в ответ на GET-запрос возвращает JSON-ответ c телом вида

{
    "user": {
        // some user fields
    },
    "expires": "2024-05-06T23:21:52.321Z",
    "accessToken": "<token>",
    "authProvider": "auth0"
}

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

Спустя год, 4 февраля 2024, уже другой исследователь опубликовал пост с подробностями своей эксплуатации. Ответ от того же самого метода API получилось закэшировать благодаря введению функциональности "шэринга" чатов: на серверах CDN было настроено правило, которое кэшировало контент по маске /share/*.
Автор смог обнаружить различие в обработке пути (path) на стороне CDN и сервера приложения и скрафтить URL, который попадал под правило кэширования на CDN, но при этом обрабатывался иначе на самом приложении.

Здесь, кроме кэша, хочу отметить само наличие подобного метода, которое к утечкам токена и приводит. В параметре "accessToken" при этом возвращается JWT со сроком жизни 10 дней 🤷‍♂️
Если покопать, обнаруживаем, что это вообще стандартный эндпоинт в используемой у openai библиотеке NextAuth.js. В v3 документации, вместо текущей v4, у них прям такой пример ответа с accessToken и приводится. Причем в своей документации коллбэков пишут, мол, по умолчанию токен не отдаем для безопасности, но вы себе это можете задать сами.

Атаки на кэш вообще - интересная тема, можно почитать про примеры в статье https://bo0om.ru/web-cache-deception-attack, там есть еще про cache poisoning. А web cache deception (обман веб-кеша) совсем молодая еще по меркам интернета: появилась только в 2017 году.

#security #article

Shared Signals Framework (SSF)

Если вы когда-нибудь пробовали шагнуть навстречу Zero Trust в энтерпрайзе, то понимаете, насколько непросто может быть интегрировать IdM`ы с SIEM`ами, SIEM`ы с IAM`ами, а IAM`ы еще с парой-тройкой решений. И причина часто банальна: это все разные вендоры и решения. Каждый вендор может иметь (или вообще не иметь) свои API, и подружить их порой становится нетривиальной задачей.

О подобной проблеме задумались и ребята из OpenID Foundation, создав для ее решения стандарт - Shared Signals Framework (SSF), ранее также известный как "Shared Signals and Events Framework". Это разрабатываемый стандарт, который нацелен на унификацию формата интеграций для асинхронного обмена сообщениями о событиях, связанных с сессией субъекта или самим субъектом в контексте безопасности. По задумке авторов он должен помочь реализовывать комплексные решения, упрощая зоопарк интеграций, где каждый вендор может предоставлять свои API для отправки/получения сообщений о подобных событиях.

В SSF выделяется 5 ключевых понятий:
1. Subject - это сущность, о которой сообщается информация при помощи события. Ей может быть пользователь, система, устройство, организация и т.д.
2. Event - событие в контексте безопасности, относящееся к Subject. В терминологии авторов событие тождественно сообщению о событии
3. Transmitter - сторона-отправитель событий
4. Receiver - сторона-получатель событий
5. Stream - введенная абстракция для способа передачи событий от Transmitter к Receiver

Shared Signals Framework основывается на существующей концепции Security Event Tokens (SET) и использует данную структуру как формат передаваемых сообщений. Это означает, что при необходимости "события" могут быть подписаны и зашифрованы (помним про JWS и JWE).

В стандарте есть два основных типа событий: CAEP и RISC
▫️CAEP (Continuous Access Evaluation Profile) - события, связанные с сессией субъекта
▫️RISC (Risk Incident Sharing and Coordination) - события, связанные с учетной записью субъекта

Фреймворк SSF сейчас поддерживает два способа доставки событий:
▫️Push delivery over HTTP - RFC 8935
▫️Poll delivery over HTTP - RFC 8936

Насколько мне удалось понять из клубка ссылающихся друг на друга черновиков и RFC, хоть понятие Stream и есть абстракция над способом передачи событий, на первых порах авторы решили ограничиться специфицированием коммуникации через HTTP как наиболее простого варианта.
Если изучить более ранние версии того же RFC 8935 " Push-Based Security Event Token (SET) Delivery Using HTTP", то в последней перед становлением RFC версии - 14-ой - можно увидеть Appendix B. Other Streaming Specifications, который "to be removed prior to publication". В нем авторы приводят рассмотренные альтернативы передаче через HTTP и, например, для Kafka пишут:

It prescribes some interesting general-purpose features that seem to extend far beyond the simpler streaming model that SECEVENTs is after.

Звучит красиво, дайте две? Но есть нюанс. Сейчас этот стандарт еще находится в стадии Implementer’s Draft и дорабатывается. Вендоры и решения его практически не поддерживают. Имплементаций в интернете - кот наплакал, и те в основном не боевые, а уровня PoC. Соответственно, если намереваться использовать, то всю реализацию придется делать самим. Хотя, кажется, движение в сторону применения в продакшене уже идет: Apple на своей WWDC, рассказывая про Managed Apple IDs, упомянули:

This integration uses three standards: OpenID Connect for federated authentication, System for Cross-domain Identity Management, or SCIM, for directory sync, and the OpenID Shared Signals Framework for account security events

Те же Okta, с которыми и был пилот, пишут, что с января начали бета-релиз этого решения.

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

#iam_general

Также для ознакомления можно посмотреть краткую и симпатичную презентацию. Никакого "Deep Dive" там нет и в помине, смотрится легко

#iam_general

Опубликовал статью на основе своего осеннего доклада с ArchDays 2023

https://habr.com/ru/articles/790272/

#my_publication

Возникающий порой вопрос: как делают получение токена по OAuth 2.0/OIDC без участия браузера, то есть из своего UI?

В оригинальном OAuth 2.0 есть Resource Owner Password Credentials grant flow, который предполагает передачу учетных данных от пользователя к Client, а Client, используя их, а заодно и свои учетные данные, выполняет запрос на получение access token. Понятно, что в данном случае учетные данные пользователя явно проходят через третью сторону, да и по дефолту данный grant flow был заточен только под один фактор. Особой популярности и применения он вроде бы не нашел, а в OAuth 2.1 его и вовсе выпиливают.
Тем не менее, порой возникают случаи, когда в угоду UX или иным причинам, рассматривается отображение форм ввода учетных данных в самом приложении, а не на стороне Authorization server.

Есть такие ребята - Curity. Они предлагают свое решение этого вопроса и даже придумали ему модное название - "Hypermedia Authentication API (HAAPI)".
Сначала надо отметить, что идея заменить отображение страниц в процессе authorization code grant flow на аналогичные API-запросы не нова. Те же ForgeRock сделали (открывать с зарубежного IP) это у себя еще давно через отдельный API и callback mechanisms.
Что предлагают Curity, попробуем понять с помощью их статьи (приложена ниже).
Во-первых, они так же, как в примере выше от ForgeRock, фокусируются на понятии hypermedia. Идея строится на том, чтобы отдавать клиенту (клиентской части) описание тех действий, которые он должен выполнить, а клиент при этом может динамически подстраиваться под ответ. Если когда-нибудь сталкивались с т.н. backend-driven UI, то это примерно оно и есть.
Но также они делают еще акцент на определении "происхождения" (provenance) Client, и для этого придумали хитрую цепочку: приложению нельзя просто так взять и начать использовать HAAPI, для этого нужно пройти ряд приседаний. Если коротко:
1. Сначала приложение запрашивает у Authorization server (AS) специальный "challenge" для указанного client_id
2. Приложение с помощью API своей платформы (различается для мобильных приложений и веба) должно подписать хэш данного challenge - challenge response - и отправить его назад вместе с оригинальным challenge
3. В ответ на это AS выпускает первый специальный вид токена - Client Attestation Token (CAT), это JWT, подтверждающий "аттестацию" (attestation) Client
4. Затем полученный CAT используется, чтобы аутентифицировать "an attested Client" в запросе на получение AAT (еще один тип токена!), CAT передается в параметре "client_assertion", аутентификация выполняется с помощь Assertion Framework (см. п. 6.1 RFC 7521)
5. AS при успехе возвращает AAT (double-A-T) - API Access Token - специальный токен, который используется только для аутентификации запросов к HAAPI
6. И только затем Client может начать выполнять запросы к HAAPI, в ответ на которые будет получать, например, указания о следующем шаге в цепочке аутентификации
7. После успешного прохождения всей цепочки Client так же с помощью HAAPI получает authorization code, которым уже может быть получен настоящий access token для доступа к ресурсам

И все это сверху приправлено еще и DPoP (Demonstrating Proof-of-Possession). Примерную схему такого процесса приложу ниже.

Что еще интересного есть:
▫️Ребята делают ограничение, что такая задумка предназначена только для public clients. Хотя результатом работы HAAPI является получение authorization code, так что вполне вероятно, что подход с получением access token с бэкенда тоже можно организовать при желании
▫️Сильно подсвечивают важность разделения First- и Third-party Clients. Для Third-party рекомендуют подумать, можно ли использовать другие факторы, а не пароль, да и вообще использовать MFA, а еще явно запрашивать пользовательское согласие (consent), что в First-party приложениях часто опущено
▫️Хитрый механизм для получения challenge response для веба с iframe и WASM-модулем. См. Appendix 6 статьи

Еще можно посмотреть их ссылки:
- пример процесса 1
- пример процесса 2
- детали по security-вопросам
- пример настройки для веб-сценариев
- developer guide

#oauth

Microsoft тут недавно выпустили курс по основам кибербезопасности Security-101. Пробежался, сами материалы действительно базовые, выделить нечего.

Но вот что мне понравилось, так это акцент в самом начале на понятиях уязвимость, атака, угроза, риск.
Очень плюсую к тому, что понимать суть этих слов и уметь их отличать (и не путать угрозы с рисками) - это важно и полезно всем, независимо от роли.
Приводят определения угрозы (threat), уязвимости (vulnerability) и риска (risk), но почему-то забыли написать про атаку (attack), хоть на картинке и нарисовали.

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

А почитать про остальные понятия можно по ссылке:
https://github.com/microsoft/Security-101/blob/main/1.3%20Understanding%20risk%20management.md

#security

Для кого предназначен токен?

Это интересный вопрос, который хотелось бы хотелось видеть почаще в контексте обсуждения реализаций схем OAuth 2.0/OIDC. Понимание того, какой компонент системы должен работать с тем или иным токеном, позволяет реализовывать более предсказуемые схемы и не порождать ошибочные риски или же ошибочные решения в принципе, где мы начинаем использовать токены не для того, для чего они были предназначены, тем самым, уходя от механизмов, предоставляемых стандартами, и добавляя себе поле для ошибок и уязвимостей (если мы, конечно, явно это не осознаем)

Какие вообще роли у нас есть в OAuth 2.0/OIDC:
- Resource owner (user)
- Client (Relying Party, Service Provider, application)
- Authorization server (OpenID Provider)
- Resource server (service, API)

Какие виды токенов бывают:
🟢 Access token
Access token получает приложение (Client) для совершения действий от лица пользователя в рамках тех scopes, к которым пользователь этот доступ делегировал. Не пользователю токен выдаётся, нет. А именно приложению. Токен доступа в конечном счёте предназначается для Resource server, имея его, приложение может выполнить то или иное действие от лица пользователя (delegation). Это значит, что хоть само приложение и владеет токеном, но воспринимать оно его должно как некую абстрактную строку. В ванильных имплементациях приложение не должно опираться структуру токена или пытаться что-то из него извлечь. В этом и кроется одна из проблем использования JWT в качестве access token: мы не можем гарантировать, что приложение само не будет как-либо полагаться на его payload или не будет пытаться получить Identity пользователя из него (что не является хорошей практикой, для этого предназначен другой тип токена). А оно не должно, access token ему выдаётся, но предназначается для обращения к Resource Server. В том числе и в части OIDC-эндпоинта userinfo, где роль Resource server выполняет Authorization server.
🟢 ID token
Ключевое отличие в том, что идентификационный токен в формате JWT выдаётся самому приложению и предназначается для использования им же. Приложение может получить этот токен в ответ на Token request и использовать его, чтобы доверенным образом узнать, а кто пользователь такой. Поэтому задачу получения Identity на стороне приложения в общем случае следует решать не парсингом JWT-access token и не походом в Introspection endpoint (куда по-хорошему его вообще пускать-то не надо часто), а получением, проверкой и обработкой ID token, либо же походом в userinfo-эндпоинт с access token.
🟢 Refresh token
Данный тип токена выдаётся приложению, а его конечным получателем (recipient) является сам Authorization server. Refresh token позволяет приложению получить новый access token даже в тех случаях, когда пользователь уже не присутствует. Соответственно он предназначен только для этого и для других целей его использовать не стоит.

#oauth