немного по теме авторизации в REST API- сервисы. чтобы авторизоваться, достаточно всего лишь... жми!

поразбирался в теме немного.

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

OAuth - это ,вот, спецификация, которая позволяет логиниться через Google и Fb.

в asp.net Core есть поддержка для авторизации через дохрена всего, в т.ч. даже Вконтакт и Одноклассники (в смысле, есть реализация подключения к их авторизации в на своем вэб-приложении)

виды авторизации сервисов REST API:

базовая авторизация - заголовок Authorization: Basic <base64 логин:пароль>

Bearer-аутентификация - Authorizarion: Baearer <BearerToken>, а сам токен получаем через отправку логина-пароля в метод авторизации API. ну типа похоже на обычную куки-авторизацию на сайтах

есть еще тип авторизации, когда токен зашифрован асинхронно, и не нужно для его проверки лазить куда-то в БД, как для ~сайтовских куки.

вроде как, это - Json Web Token - JWT. ну или по крайней мере это - стандарт для создания подобных токенов

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

(ну и еще какие то виды авторизации, наверное, я уже внимание не заострял)

ссылки, которые могут пригодиться (хотя, не факт):

https://stackoverflow.com/a/59670260/1438829 - полезненько. описывается базовая аутентификация и Bearer-token-аут-я (принцип работы)

https://habr.com/ru/company/Voximplant/blog/323160/ - объясняется, зачем нужен refresh-токен в дополнение к access-токену. прикольно. гарантирует, что если злоумышленник украдет пару токенов - они у него помрут максимум по окончании времени жизни аксесс-токена (а оно по задумке невелико - несколько десятков минут)(хотяяя, если рефреш похитит тоже - что помешает ему работать с сервисом параллельно с , собственно, пользователем, который переавторизуется ~через логин-пароль?)

Стандарты авторизации, их соотношение.

OpenId Connect - он же OIDC - протокол, позволяющий логиниться с помощью ~провайдеров логина (google, FB...). работает поверх OAuth 2, поверх TLS/SSL/HTTPS. использует JWT.

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

Json Web Token - формат JSon-объекта, который передается авторизованному пользователю и используется в дальнейшем как токен доступа. что- то типа старого доброго куки-токена . но куки-токен при обработке каждого запроса нужно проверять, что мы такой выдавали (сверяться с БД, например). а инфа в JWT подписана (а мож и зашифрована?) создателем (issuer) JWT. и подпись может быть проверена приложением-пользователем сервиса авторизации. поэтому не обязательно каждый раз сдавать JWT issuer'у на проверку.

как соотносятся OAuth2 и OIDC

https://www.transmitsecurity.com/blog/oidc-vs-oauth2 :

OAuth2 focuses on authorization, not authentication. The assumption is that Google, Facebook, etc. has performed strong authentication and is confident about a user’s identity

OIDC is an extension of OAuth2 that focuses on user authentication rather than user authorization. Once OIDC authenticates a user, it uses OAuth2 specifications to perform authorization.

OAuth2 is focused solely on authorization, while OIDC supports authentication and authorization

*OIDC = OpenID Connect

хмм, то есть, логика соотношения OIDC и OAuth такая:

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

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

... который ты можешь в рамках OAuth пихать в последующие API-вызовы. то есть, OIDC заостряет внимание именно на процессе аутентификации.

сейчас, когда говорят " OAuth" - обычно подразумевают OAuth2 . это - широко распространенный стандарт. тогда как OAuth 1 в свое время был заточен под Twitter API. ну и сейчас им особо никто, я так понимаю, не пользуется.

OIDC - вроде, более молодой и менее распространенный. OAuth 2 - я так понимаю, широко распространен.