Как ответил jwilleke, OAuth 2.0 для авторизации. OpenID Connect (OIDC) построен на OAuth 2.0 и добавляет уровень аутентификации.
По сути, OAuth 2.0 делегирует клиентскому приложению доступ к защищенной конечной точке от имени владельца ресурса. Проще говоря, конечный пользователь разрешает приложению доступ к ресурсу / услуге. В этом процессе приложение не получает никаких сведений о конечном пользователе, поэтому оно не может аутентифицироваться / обнаруживать (в OIDC приложение получает токен идентификатора, который самодостаточен для аутентификации конечного пользователя).
В: Является ли идея, что после того, как мобильное приложение получит токен доступа oauth2 -> они всегда должны подключаться к какой-либо конечной точке, например / me, используя этот токен доступа, который затем предоставит информацию об идентификаторе пользователя? и, следовательно, API должен отслеживать, какие токены доступа были предоставлены каждому конкретному пользователю?
С точки зрения OAuth 2.0 обмен информацией с конечным пользователем отсутствует. Но провайдер идентификации, выдающий токены, понимает токены, которые он выпустил. Внутренне он может отображать данные конечного пользователя, разрешения и все, что требуется для его обработки. При этом, когда API (сервер ресурсов) получает токен доступа, он может проверить токен. Обратите внимание, что ресурсный сервер и авторизация могут быть одинаковыми или разными. И это детали реализации. В качестве альтернативы можно использовать самоконтроль токенов, как определено в rfc7662 , для определения допустимости проблем с токенами доступа.
Пример сценария
У вас есть мобильное приложение A. И у него есть возможность использовать службу B (защищенную токенами доступа), предоставляемую поставщиком услуг G. Предположим, есть пользователь Alex, который уже зарегистрирован в SP G, поэтому у него есть доступ к служба B использует приложение A. И в SP G реализована OAuth 2.0, поэтому служба B принимает маркеры доступа, выпущенные SP G.
Пользователь Alex использует приложение A, и в приложении A есть функциональность, которая должна использовать службу B. Приложение A требует авторизации от Alex для использования службы B от его имени. При этом будет происходить процесс входа пользователя, и в конце SP G выдаст токен доступа к приложению A. Передает ли он личность Алекса? Нет. Но приложение A теперь может использовать службу B, используя полученный токен доступа. Служба B полностью понимает и может проверять проблемы маркеров доступа с помощью SP G. IMO Это OAuth 2.0 в двух словах.
p.s - Замените известные сервисы, такие как календарь Google, идентификационные данные Google и приложение для Android, чтобы они стали более понятными.