Кто / Что именно является клиентским приложением в потоке кода аутентификации Open ID Connect?

Question

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

Учитывая:

• Аудитория ID_Token предназначена для Client_Application
• Аудитория Access_Token предназначена для API защищенных ресурсов
• У нас есть интерфейсный SPA, имеющий собственный веб-интерфейс (который впоследствии может использоваться другими клиентами)

Используются следующие компоненты:

1. Front-end SPA (проверяющая сторона)
2. Back-end Web_API (защищенный ресурс)
3. OpenID Provider (OP )

Если бы я хотел применить поток кода авторизации, когда пользователь получает доступ к Front-end SPA, будет ли Front-End SPA ИЛИ Web_API рассматриваться как Client_Application? В потоке кода авторизации фактический обмен Auth_Code для ID_Token будет происходить по обратному каналу через Back-end Web_API к OP. Тем не менее, это действительно Front-end SPA, который первоначально запрашивал аутентификацию пользователя. Какой должна быть / будет аудитория ID_Token - это будет App_ID SPA или Web_API?

Спасибо за любую помощь с разъяснением.

Answer 1

В соответствии с современными рекомендациями, SPA должен использовать поток кода авторизации с PKCE ( черновик из лучших практик rf c). Поэтому, пожалуйста, учтите это при использовании OAuth с вашим SPA.

Что касается ваших сомнений, вот ваш клиент и аудитория

• Клиент - Ваш SPA
• Аудитория Идентификационный токен - Ваш SPA
• Аудитория Маркер доступа - Внутренний веб-API

Обоснование:

Это ваш SPA, который завершает поток OAuth и получает токены. И, как я уже сказал, он должен следовать за PKCE в качестве текущей рекомендации (для этого достаточно библиотек). Таким образом, с точки зрения сервера авторизации, клиент - это ваш SPA.

Что касается идентификатора токена, он предназначен для использования вашим SPA. После проверки подлинности SPA аутентифицируйте конечного пользователя. Таким образом, целевой аудиторией является SPA.

Маркер доступа предназначен для использования в вашей бэкэнде вашим SPA. Как только он получает запрос API, он должен проверить, что аудитория маркера доступа содержит идентификатор, нацеливающий себя (например: - Если JWT, утверждение, содержащее backdene identifeir. Или, если самоанализ токена, resposne, содержащий идентификатор). Обычно ваш сервер авторизации позволяет вам регистрировать такие аудитории, и ваш запрос на авторизацию может иметь заданный параметр аудитории (например: - Azure использовать этот подход). Но это особенности реализации.