Что такое клиентское приложение, которое предполагается использовать с JWT, полученным через OpenID Connect?

Question

У меня есть сценарий, где OIDC кажется подходящим: мобильное приложение, в котором пользователям нужно будет получать некоторые частные данные с сервера. Я читал учебники OIDC such as this one, и я думаю, что я их понял, но по-прежнему остается решающее окончательное «отверстие» в глобальной картине.

Во всяком случае, если я правильно понял код потока РСИН, это краткое резюме взаимодействий:

1. Мобильное приложение связывается с конечной авторизации ОИС, указав в scope, который нам нужен в электронная почта пользователя. Он обеспечит как redirect_uri указатель на простой веб-сервер, запущенный в самом мобильном приложении.
2. OIP свяжется с мобильным приложением через redirect_uri и предоставит ему код авторизации.
3. Мобильное приложение теперь свяжется с конечной точкой маркера OIP и предоставит ему код авторизации, полученный на шаге 2. Он также предоставит OIP redirect_uri, где должен быть отправлен ответ.
4. OIP свяжется с приложением через redirect_uri и предоставит ему подписанный JWT с запросом (электронной почтой), который мы просили.

И здесь заканчиваются учебные пособия. Я предполагаю, что теперь подразумевается, что мобильное приложение отправит JWT, полученный на шаге 4, на мой сервер. Однако как сервер должен знать, что JWT действителен? Несомненно, он подписан OIP, но сервер должен иметь жесткий список открытых ключей OIP для проверки JWT? Эти последние важнейшие шаги, кажется, отсутствуют в учебниках по OIDC, которые я нашел ...

Answer 1

Поток кода авторизации OpenID] несколько отличается в пункте 4. После получения маркера авторизации клиент запрашивает идентификатор маркера на конечную точку маркера , который возвращает ответ, который включает в себя ID Знак, без перенаправления (запрос должен включать redirect_uri параметров и сервер будет гарантировать, что совпадает с оригиналом)

Это полная OpenID Authorization code flow

1. Клиент готовит запрос аутентификации, содержащий требуемые параметры запроса .
2. Клиент отправляет запрос на авторизацию Server.
3. Сервер авторизации Аутентификация конечного пользователя.
4. Сервер авторизации получает согласие/авторизацию конечного пользователя.
5. Сервер авторизации отправляет конечного пользователя обратно Клиенту с помощью кода авторизации.
6. Клиент запрашивает ответ с использованием кода авторизации на конечной точке токена.
7. Клиент получает ответ, содержащий идентификатор и токен доступа в корпусе ответа.
8. Клиент проверяет идентификатор и извлекает идентификатор объекта конечного пользователя.

Наконец, клиент должен проверить маркер в соответствии 3.1.3.4 ID Token Validation.Резюме важных моментов будет:

• iss содержит идентификатор эмитента и aud ваш client_id

• текущее время между iat и exp

• Validate подпись лексем с помощью ключи, предоставленные Эмитентом. В этом потоке проверка сервера TLS может использоваться для проверки эмитента вместо проверки сигнатуры маркера. В случае HMAC, client_secret из client_id используется в качестве ключа для проверки

• Validate nonce, azp или azr испрашивается