Как создать известный конфигурационный файл для open id connect?
У нас есть реализация openid connect, которая возвращает закодированный токен id, это работает хорошо и работает некоторое время. Однако мы пытаемся подключиться к нему с помощью cognito в aws, и после небольшой проб и ошибок мы обнаружили, что нам не хватает файла .well-known / openid-configuration.
Этот файл должен содержать информацию о вызовах к имеющемуся у нас серверу openid-connect, включая ключи JWK.
Я не понимаю ключи JWK, это означает:
1. Как их генерировать
2. После того, как сгенерировано, что с ними делать?
3. Нужно ли изменять существующий код, который у нас есть для openid-connect, и использовать ключи JWK?
4. Есть ли способ проверки конфигурации openid-connect?
Некоторое время назад я спрашивал нечто подобное, но безрезультатно, но возвращаюсь.
Спасибо
Kevin
Что я уже пробовал:
Был тут: https://mkjwk.org/ и щелкнул «Новый ключ», который возвращает то, что, как я полагаю, является веб-ключом… однако не знаю, что я собираюсь делать с ним или что означают другие вкладки на нем.
Ожидаемые результаты:
Ожидается, что AWS Cognito продолжит работу и позволит подключиться к нашей реализации open id connect. В настоящее время просто получаю сообщение об ошибке в связи с отсутствующим хорошо известным файлом конфигурации.
Решение
Сервер openid connect у вас генерирует ID-токен, который является JWS.
Эти токены подписаны с использованием закрытого ключа (EC, RSA или OKP).
Хорошо известная конфигурация openid должна содержать объект JSON, который указывает, какие алгоритмы используются для подписи токенов, и URL-адрес для получения открытых ключей, связанных с закрытыми ключами, используемыми для подписи токена.
Например, Конфигурация сервера аккаунта Google указывает, что открытые ключи можно найти на https://www.googleapis.com/oauth2/v3/certs (jwks_uri параметр).
По этому адресу вы найдете список ключей (JWKSet), отформатированных в JWK (JSON Web Keys). Эти форматы (JWK и JWKSet) являются стандартными представлениями ключей и наборов ключей, используемых в контексте JWT (см. RFC7517).
- Как их генерировать
Обычно у вас уже есть хотя бы один закрытый ключ для подписи ваших токенов, поэтому вам не нужно создавать новый.
- После того, как сгенерировано, что с ними делать?
Закрытый ключ, который у вас есть, должен быть PEM (начиная с ------ PRIVATE RSA KEY ----- или аналогичный) или ключ DER.
Вам просто нужно конвертировать этот ключ в JWK.
я создал небольшое приложение PHAR (PHP) это поможет конвертировать ваши ключи. Это приложение является частью Web Token Framework но может быть установлен как отдельное приложение. Убедитесь, что у вас установлены расширения PHP 7.1, OpenSSL и JSON.
Когда приложение установлено, вы можете выполнить следующую команду:
jose key:convert:public $(jose key:load:key PATH_TO_YOUR_KEY)
Эта команда преобразует закрытый ключ в JWK, а затем преобразует его из частного в открытый.
Результатом можно поделиться через конечную точку jwks_uri.
- Должен ли существующий код, который у нас есть для openid-connect, изменить и использовать ключи JWK?
Нет. То, как вы строите свои токены, не означает, что вы должны что-то менять.
- Есть ли способ проверки конфигурации openid-connect?
Насколько я знаю, нет инструментов для проверки объекта конфигурации. Вы должны обратиться к спецификации OpenID Connect.
Другие решения
В то время как Флорент отвечает на использование открытого ключа, я хотел бы указать вам на спецификацию, которая определяет содержание JWK и конкретные детали реализации.
OpenID Connect discovery определить документ открытия. Там вы найдете jwks_uri URL как часть метаданных, которая указывает на JSON Web Key Set
3. Метаданные провайдера OpenID
wks_uri
ТРЕБУЕТСЯ. URL-адрес документа OP JSON Web Key Set документа [JWK]. это
содержит ключ (ы) подписи, которые RP использует для проверки подписей от
ОП
Теперь это указывает на RFC7517 — веб-ключ JSON (JWK). Там вы можете найти точную информацию о каждом поле полезной нагрузки JSON. Обратитесь к его образцам и разделу приложения, чтобы увидеть образец содержимого. И ваша реализация должна следовать спецификационным требованиям, определенным этим.
Для кодирования, если вы используете JAVA, я предлагаю вам использовать Библиотека Nimbus JOSE + JWT. Образец можно найти из этого ссылка на сайт.
Например, если у вас уже есть X509Certificate загружен, затем следующий минималистичный код для генерации JWK. Он встроен в сервлет [Полный источник].
import Common.CertificateLoader;
import Common.Exceptions.FrameworkUncheckedException;
import com.nimbusds.jose.JOSEException;
import com.nimbusds.jose.jwk.JWK;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.security.cert.X509Certificate;
@WebServlet(urlPatterns = "/openid-configuration/jwks_uri")
public class JWKDocument extends HttpServlet {
@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException {
// NOTE - LOAD YOUR CERTIFICATE HERE
final X509Certificate certificate = CertificateLoader.getCertificateLoader().getX509Certificate();
final JWK jwk;
try {
jwk = JWK.parse(certificate);
} catch (JOSEException e) {
throw new FrameworkUncheckedException("Error while loading to JWK", e);
}
resp.getOutputStream().print(jwk.toJSONString());
}
}