OAuth2, JWT, Open-ID Connect и другие запутанные вещи

отказ

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

миссия

Я решил написать этот пост, потому что я всегда находил OAuth2 запутанным . Даже теперь, когда я знаю немного больше об этом, я нашел некоторые его части озадачивающими.
Даже если бы я мог следить за онлайн-уроками от таких как Google или Pinterest, когда мне нужно было поиграться с их API, это всегда было своего рода вуду со всеми этими кодами и токенами на предъявителя.
И каждый раз, когда они упоминали, что я мог принимать свои собственные решения для конкретных шагов, выбирая из стандартного подхода OAuth2, мой ум склонен ослепать.

Я надеюсь, что смогу исправить некоторые идеи, так что теперь вы сможете с большей уверенностью следовать учебным пособиям OAuth2.

Что такое OAuth2?

Давайте начнем с определения :

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

Приведенное выше предложение вполне понятно , но мы можем улучшить ситуацию, если точно определим выбранные термины.

Часть имени Auth показывает себя как Авторизация (это могла быть Аутентификация; это не так).
Структура может быть легко пропущена, поскольку термином «структура» часто злоупотребляют; но идея сохранить здесь заключается в том, что это не обязательно конечный продукт или что-то полностью определенное . Это набор инструментов. Коллекция идей, подходов, четко определенных взаимодействий, которые вы можете использовать, чтобы построить что-то поверх этого!
Это позволяет приложениям получать ограниченный доступ . Ключевым моментом здесь является то, что он позволяет приложениям, а не людям .
ограниченный доступ к учетным записям пользователей, вероятно, является ключевой частью определения, которое может помочь вам вспомнить и объяснить, что такое OAuth2:
Основная цель — дать пользователю возможность делегировать доступ к пользовательскому ресурсу. Делегирование это приложению.

OAuth2 о делегировании.

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

Делегация перед OAuth2

Теперь, когда контекст стал более понятным, мы могли бы спросить себя: как все было сделано до появления OAuth2 и подобных концепций?

Ну, в большинстве случаев это было так плохо, как вы можете догадаться: с общим секретом .

Если я хотел, чтобы программному обеспечению A был предоставлен доступ к моим материалам на сервере B, большую часть времени подход заключался в том, чтобы передать моего пользователя / передать программное обеспечение A, чтобы оно могло использовать его от моего имени. Это все еще образец, который вы можете видеть во многих современных программах, и я лично надеюсь, что это заставит вас чувствовать себя неловко. Вы знаете, что они говорят: если вы делитесь секретом, это больше не секрет!

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

OAuth2 — идея

Помня о том, что бизнес-проблема, которую мы пытаемся решить, — это «делегирование», мы хотим расширить идею специальных паролей, чтобы избавить пользователя от бремени управления этими специальными паролями.
OAuth2 называет эти специальные пароли токенами .
Токены — это на самом деле нечто большее , и я попытаюсь проиллюстрировать это, но для начала было бы полезно связать их с этой более простой идеей специального пароля.

OAuth2 — основной бизнес

Основной бизнес Oauth 2 — это:

• как получить токены

OAuth2 — Что такое токен?

Поскольку все, кажется, сосредоточено вокруг токенов, что такое токен?
Мы уже использовали аналогию со специальным паролем, который до сих пор служил нам хорошо, но, возможно, мы сможем добиться большего.
Что если мы ищем ответ в спецификациях OAuth2?
Ну, приготовьтесь разочаровываться. Спецификации OAuth2 не дают подробностей о том, как определить токен. Почему это вообще возможно?
Помните, когда мы говорили, что OAuth2 был «просто фреймворком»? Ну, это одна из тех ситуаций, где это определение имеет значение!
Спецификации просто говорят вам логическое определение того, что такое токен, и описывают некоторые возможности, которыми он должен обладать.
Но в конце, спецификации говорят, что токен является строкой. Строка, содержащая учетные данные для доступа к ресурсу.
Это дает некоторые подробности, но можно сказать, что в большинстве случаев не очень важно, что находится в токене. Пока приложение может их потреблять.

Токен — это то, что позволяет приложению получать доступ к интересующему вас ресурсу.

Чтобы указать, как можно избежать переосмысления того, что такое токен, спецификации также прямо говорят, что «обычно непрозрачны для клиента»! Они практически говорят вам, что вы даже не обязаны их понимать! Меньше вещей, чтобы иметь в виду, не звучит плохо!

Но чтобы не превращать это в урок чистой философии, давайте покажем, каким может быть токен

Быстрый взгляд показывает нам, что да, это строка. Подобный JSON, но это, вероятно, только потому, что в последнее время популярность json не обязательно является обязательным требованием. Мы можем найти раздел с чем-то похожим на случайную строку, id: 363tghjkiu6trfghjuytkyen . Программисты знают, что когда вы видите что-то подобное, по крайней мере, когда строка не слишком длинная, это, вероятно, признак того, что это просто ключ, который вы можете соотнести с более подробной информацией, хранящейся где-то еще. И это верно и в этом случае. Более конкретно, дополнительной информацией будет информация о конкретной авторизации, которую представляет этот код.

Но тогда другое внимание должно привлечь ваше внимание: "token_type": "Bearer" .

Ваши разумные вопросы должны быть такими: каковы характеристики типа токена на Bearer ? Есть ли другие типы? Какие?

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

Спецификации говорят только о типе токена на Bearer !

Так почему же человек, создавший токен таким образом, решил, что ему нужно указать единственное известное значение? Вы можете начать видеть образец здесь: потому что OAuth2 — это просто фреймворк!
Он предлагает вам, как что-то делать, и делает тяжелую работу за вас, делая некоторый выбор, но в конце вы несете ответственность за использование фреймворка для создания того, что вы хотите.
Мы просто говорим, что, несмотря на то, что здесь мы говорим только о Bearer , это не означает, что вы не можете определить свой пользовательский тип со значением, которое вам разрешено приписывать ему.

Хорошо, только один тип. Но это любопытное имя . Подразумевает ли название что-нибудь актуальное? Может быть, это глупый вопрос, но для не носителей английского языка, таких как я, то, что в данном случае означает Bearer может быть немного запутанным.

Его значение довольно просто на самом деле:

Токен на предъявителя — это то, что, если у вас есть действительный токен, мы доверяем вам. Никаких вопросов не было задано.

Так просто, это сбивает с толку. Вы можете возразить: «ну, все подобные объекту объекты в реальном мире работают так: если у меня есть действительные деньги, вы меняете их на то, что вы продаете».

Верный. Это действительный пример токена на предъявителя.

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

Чтобы подвести итог, мы работаем с определенными токенами, которые, если у вас есть один из них, этого достаточно, чтобы получить доступ к ресурсу.

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

Аналогия с токеном

Еще раз, это может быть мой не родной английский фон, который предлагает мне уточнить это. Когда я ищу первый перевод токена на итальянский, мой родной язык, я указываю на физический объект. Что-то вроде этого:

Это, в частности, старый токен, используемый для телефонных звонков в общественных телефонных будках. Несмотря на то, что он является токеном на предъявителя, его аналогия с токенами OAuth2 довольно плохая.
Тим Брэй в этом старом посте разработал гораздо лучшую картину: ключ отеля — это токен доступа. Я предлагаю вам прочитать статью непосредственно, но основная идея заключается в том, что по сравнению с физической металлической монетой, которую я сначала связал Ваш программный токен может иметь продолжительность жизни, удаленно отключаться и содержать информацию.

Актеры участвуют

Это наши актеры:

• Владелец ресурса
• Клиент (иначе Приложение)
• Сервер авторизации
• Защищенный ресурс

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

Обычно, когда читаю что-то новое, я склонен быстро пропускать актеров системы. Вероятно, я не должен, но в большинстве случаев параграф, в котором говорится, описывает, например, «пользователя», в конечном итоге использует много слов, чтобы просто сказать мне, что это просто, ну, в общем, пользователь… Поэтому я пытаюсь найти термины, которые менее интуитивны и проверяют, есть ли у некоторых из них какая-то особенность, на которую я должен обратить особое внимание.

В конкретном случае OAuth2 я чувствую, что актер с самым запутанным именем — Клиент .
Почему я так говорю? Потому что в обычной жизни (и в ИТ) это может означать много разных вещей: пользователь, специализированное программное обеспечение, очень универсальное программное обеспечение…

Я предпочитаю классифицировать это в своем уме как приложение .

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

Я думаю, что это очень важно. Термин «клиент» повсеместен, поэтому я предлагаю не полностью его заменять, а заставить мозг думать о взаимоотношениях « клиент = приложение» .

Мне также нравится думать, что есть еще один не официальный актер: пользователь-агент.

Я надеюсь, что я не буду путать людей здесь, потому что это полностью то, что я использую для построения своей ментальной карты.
Несмотря на то, что он не определен в спецификациях, а также не присутствует во всех различных потоках, он может помочь идентифицировать этот пятый субъект в потоках OAuth2.
Пользователь-агент большую часть времени выдает себя за веб-браузер. Его обязанность заключается в том, чтобы обеспечить косвенное распространение информации между двумя системами, которые не взаимодействуют друг с другом напрямую.
Идея такова: А должен поговорить с Б, но это запрещено. Таким образом, A говорит C (User-Agent) что-то сказать B.

Это может быть немного запутанным в данный момент, но я надеюсь, что смогу прояснить это позже.

OAuth2 Core Business 2

OAuth2 о том, как получить токены.

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

Это правильно, но это только одно из множества возможных взаимодействий, которые определяет OAuth2 .

Есть 4 основных, это важно, вы знаете. И это может стать неожиданностью, если вы впервые услышите это:
не все из них будут отображать экран разрешений, подобный Google!
Это потому, что вы можете использовать подход OAuth2 даже из инструмента командной строки; может быть, даже без какого-либо пользовательского интерфейса, способного отображать вам интерактивную веб-страницу для делегирования разрешений.

Помните еще раз: главная цель — получить токены!

Если вы найдете способ получить один, часть «как», и вы сможете их использовать, все готово.

Как мы уже говорили, в OAuth2 определены четыре способа. Иногда они называются потоками, иногда они называются грантами .
Неважно, как вы их называете. Я лично использую поток, так как он помогает мне напомнить, что они отличаются друг от друга для взаимодействий, которые вы должны выполнять с различными актерами, чтобы получить токены.

Они есть:

• Поток кода авторизации
• Неявный поток грантов
• Поток учетных данных клиента
• Поток предоставления учетных данных владельца ресурса (также называемый потоком паролей)

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

Мальчик плаката OAuth2: поток кода авторизации

Мы начнем наше обсуждение с потоком кода авторизации по трем причинам:

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

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

Как получить токен с помощью кода авторизации

1. Все вовлеченные актеры доверяют серверу авторизации
2. Пользователь (Владелец ресурса) говорит Клиенту (Приложению) сделать что-то от его имени.
3. Клиент перенаправляет пользователя на сервер авторизации, добавляя некоторые параметры: redirect_uri , response_type=code , scope , client_id
4. Сервер авторизации спрашивает Пользователя, желает ли он предоставить Клиенту доступ к какому-либо ресурсу от его имени (делегирование) с конкретными разрешениями (областью действия).
5. Пользователь принимает запрос на делегирование, поэтому Auth Server теперь отправляет инструкцию User-Agent (Browser), чтобы перенаправить на URL клиента. Он также внедряет code=xxxxx в эту инструкцию HTTP Redirect.
6. Клиент, который был активирован User-Agent благодаря перенаправлению HTTP, теперь общается напрямую с сервером авторизации (в обход User-Agent). client_id , client_secret и code (чтобы он был переслан).
7. Сервер авторизации возвращает Клиенту (не браузеру) действительный access_token и refresh_token

Это так ясно сформулировано, что это также называется танцем OAuth2!

Подчеркнем пару моментов:

• На шаге 2 мы указываем, среди других параметров, redirect_uri . Это используется для реализации той косвенной коммуникации, которую мы ожидали, когда представили User-Agent в качестве одного из участников. Это ключевая информация, если мы хотим разрешить серверу авторизации пересылать информацию клиенту без прямого сетевого соединения между ними.
• scope упомянутая на шаге 2, представляет собой набор разрешений, которые запрашивает клиент
• Помните, что это поток, который вы используете, когда клиент полностью защищен. Это актуально в этом потоке на шаге 5, когда связь между Клиентом и Сервером авторизации избегает прохода через менее защищенного агента пользователя (который может перехватить или подорвать связь). Поэтому также имеет смысл, чтобы Клиент client_secret еще большую безопасность, то есть отправил свой client_secret , который используется только им и сервером авторизации.
• refresh_token используется для последующих автоматических вызовов, которые клиенту может потребоваться выполнить на сервере авторизации. Когда текущий access_token истекает и ему нужно получить новый, отправка действительного refresh_token позволяет избежать повторного запроса Пользователя на подтверждение делегирования.

OAuth2 Получил токен, что теперь?

OAuth2 — это структура, запоминаемая. Что мне сейчас говорит фреймворк?

Ну ничего. = Р

Это зависит от разработчика клиента.

Она могла (и часто должна):

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

Все они действительны и довольно очевидны, верно? Должен ли разработчик самостоятельно определить наилучший набор операций, которые необходимо выполнить дальше? Она определенно может. В противном случае она может использовать другую спецификацию: OpenIDConnect (OIDC). Подробнее об этом позже.

OAuth2 — неявный поток грантов

Это поток, разработанный для клиентских приложений, который не может держать в секрете . Очевидный пример — клиентские HTML-приложения. Но даже любое двоичное приложение, чей код открыт для общественности, можно манипулировать, чтобы извлечь свои секреты.
Не могли бы мы повторно использовать поток кода авторизации? Да, но … Какой смысл в шаге 5) если секрет больше не является безопасным секретом? Мы не получаем никакой защиты от этого дополнительного шага!
Итак, Implicit Grant Flow просто похож на поток кода авторизации, но он не выполняет этот бесполезный шаг 5.
Он направлен на непосредственное получение access_tokens без промежуточного этапа получения сначала кода , который будет передаваться вместе с секретом для получения access_token.

Он использует response_type=token для указания того, какой поток использовать при обращении к серверу авторизации. А также, что нет refresh_token . И это потому, что предполагается, что пользовательские сеансы будут короткими (из-за менее безопасной среды) и что в любом случае пользователь все еще будет рядом, чтобы повторно подтвердить свое желание делегировать (это был основной вариант использования, который привел к определению refresh_tokens ).

OAuth2 — поток предоставления клиентских полномочий

Что делать, если у нас нет Владельца ресурса или он не отличается от самого программного обеспечения Клиента (соотношение 1: 1)?
Представьте себе бэкэнд-систему, которая просто хочет общаться с другой бэкэнд-системой. Пользователи не участвуют. Основная характеристика такого взаимодействия заключается в том, что оно больше не является интерактивным, поскольку у нас больше нет пользователя, которого просят подтвердить его желание делегировать что-либо. Это также косвенно определяет более безопасную среду, в которой вам не нужно беспокоиться об активных пользователях, рискующих прочитать секреты.

Его типом является response_type=client_credentials .

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

OAuth2 — Поток предоставления учетных данных владельца ресурса (также называемый потоком паролей)

Пожалуйста, поднимите ваше внимание здесь, потому что вы собираетесь быть в замешательстве

Это сценарий: владелец ресурса имеет учетную запись на сервере авторизации. Владелец ресурса передает данные своей учетной записи Клиенту. Клиент использует эти данные для аутентификации на Сервере авторизации …

= О

Если вы прошли обсуждение, вы можете спросить, шучу ли я. Это именно тот анти-паттерн, от которого мы пытались отойти в начале нашего исследования OAuth2!

Как можно найти это перечисленное здесь как возможный предложенный поток?

На самом деле ответ вполне разумный: это возможная первая остановка миграции из устаревшей системы . И это на самом деле немного лучше, чем антипаттерн с общим паролем:
Пароль является общим, но это всего лишь способ запустить OAuth Dance, используемый для получения токенов.

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

Так что далеко от идеала, но, по крайней мере, мы обоснованы какими-то критериями.

Как выбрать лучший поток?

В интернете есть множество схем принятия решений. Один из тех, которые мне нравятся больше всего, это:

с https://auth0.com

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

OAuth2 Вернуться к токенам — JWT

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

Могут ли вещи быть лучше?

Например, мы предположили, что наши токены могут выглядеть так:

Можем ли мы получить больше информации, чтобы мы могли сэкономить на обратном пути к серверу авторизации?

Что-то вроде следующего было бы лучше:

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

К счастью, у кого-то еще была такая же идея, и они выпустили JWT — JSON Web Tokens .
JWT — это стандарт для определения структуры токенов на основе JSON, представляющих набор утверждений. Именно то, что мы искали!

На самом деле самый важный аспект, который дает нам спецификация JWT, заключается не в полезной нагрузке, которую мы проиллюстрировали выше, а в способности доверять всему токену без использования сервера авторизации!

Как это вообще возможно? Идея не нова: асимметричная подпись (pubkey), определенная в контексте JWT спецификациями JOSE .

Позвольте мне обновить это для вас:

При асимметричной подписи используются два ключа для проверки достоверности информации.
Эти два ключа связаны, но один является секретным, известным только создателю документа, а другой — общедоступным.
Секретный используется для расчета отпечатка пальца документа; хеш
Когда документ отправляется по назначению, читатель использует открытый ключ, связанный с секретным, чтобы проверить, действительны ли документ и полученный им отпечаток пальца.
Алгоритмы цифровой подписи говорят нам, что документ действителен в соответствии с открытым ключом, только если он подписан соответствующим секретным ключом.

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

И вернемся к нашему случаю использования токенов:

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

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

OpenID Connect

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

OAuth2 + JWT + JOSE ~ = OpenID Connect

Еще раз: OAuth2 — это фреймворк.
Платформа OAuth2 используется в сочетании со спецификациями JWT, JOSE и другими идеями, которые мы не собираемся здесь подробно описывать, — создавать спецификацию OpenID Connect.

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

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

Вывод

Если вас интересует эта тема или эта статья вас только смутила, я предлагаю вам проверить OAuth 2 в действии Джастина Ричера и Антонио Сансо.
С другой стороны, если вы хотите проверить свои новые знания и попытаться применить их на сервере авторизации с открытым исходным кодом, я определенно рекомендую поиграть с Keycloak , способным ко всему, что мы здесь описали, и многому другому !