«Доступ к конечным точкам Keycloak с помощью Postman»

«1. Введение

В этой статье мы начнем с краткого обзора OAuth 2.0, OpenID и Keycloak. После этого мы узнаем об API-интерфейсах Keycloak REST и о том, как их вызывать в Postman.

2. OAuth 2.0

OAuth 2.0 — это структура авторизации, которая позволяет аутентифицированному пользователю предоставлять доступ третьим лицам с помощью токенов. Маркер обычно ограничен некоторыми областями с ограниченным временем жизни. Следовательно, это безопасная альтернатива учетным данным пользователя.

OAuth 2.0 состоит из четырех основных компонентов:

Владелец ресурса — конечный пользователь или система, которой принадлежит защищенный ресурс или сервер данных. Клиент API — вызывает защищенный ресурс от имени владельца ресурса Сервер авторизации — выдает токен OAuth 2.0 и доставляет его клиенту после аутентификации владельца ресурса

OAuth 2.0 — это протокол с некоторыми стандартными потоками, но здесь нас особенно интересует компонент сервера авторизации.

3. OpenID C0nnect

OpenID Connect 1.0 (OIDC) построен на основе OAuth 2.0, чтобы добавить к протоколу уровень управления идентификацией. Следовательно, это позволяет клиентам проверять личность конечного пользователя и получать доступ к базовой информации профиля через стандартный поток OAuth 2.0. OAuth 2.0 представила несколько стандартных областей действия, таких как openid, профиль и электронная почта.

4. Keycloak как сервер авторизации

Компания JBoss разработала Keycloak как основанное на Java решение для управления идентификацией и доступом с открытым исходным кодом. Помимо поддержки как OAuth 2.0, так и OIDC, он также предлагает такие функции, как посредничество в идентификации, объединение пользователей и единый вход.

Мы можем использовать Keycloak как автономный сервер с консолью администратора или встроить его в приложение Spring. Как только наш Keycloak заработает любым из этих способов, мы можем попробовать конечные точки.

5. Конечные точки Keycloak

Keycloak предоставляет множество конечных точек REST для потоков OAuth 2.0.

Чтобы использовать эти конечные точки с Postman, давайте начнем с создания среды под названием «Keycloak». Затем мы добавляем несколько записей типа ключ/значение для URL-адреса сервера авторизации Keycloak, области, идентификатора клиента OAuth 2.0 и пароля клиента:

Затем давайте создадим коллекцию, в которой мы сможем организовать наши тесты Keycloak. Теперь мы готовы изучить доступные конечные точки.

5.1. Конечная точка конфигурации OpenID

Конечная точка конфигурации аналогична корневому каталогу. Он возвращает все остальные доступные конечные точки, поддерживаемые области действия и утверждения, а также алгоритмы подписи.

Создадим запрос в Postman: {{server}}/auth/realms/{{realm}}/.well-known/openid-configuration. Почтальон устанавливает значения {{server}} и {{realm}} из выбранной среды во время выполнения:

Затем мы выполняем запрос, и если все идет хорошо, мы получаем ответ:

{
    "issuer": "http://localhost:8083/auth/realms/baeldung",
    "authorization_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/auth",
    "token_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/token",
    "token_introspection_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/token/introspect",
    "userinfo_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/userinfo",
    "end_session_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/logout",
    "jwks_uri": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/certs",
    "check_session_iframe": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/login-status-iframe.html",
    "grant_types_supported": [...],
    ...
    "registration_endpoint": "http://localhost:8083/auth/realms/baeldung/clients-registrations/openid-connect",
    ...
    "introspection_endpoint": "http://localhost:8083/auth/realms/baeldung/protocol/openid-connect/token/introspect"
}

Как уже упоминалось ранее мы могли видеть все доступные конечные точки в ответе — например, «authorization_endpoint», «token_endpoint» и так далее.

Кроме того, в ответе есть и другие полезные атрибуты. Например, мы можем определить все поддерживаемые типы грантов из «grant_types_supported» или все поддерживаемые области действия из «scopes_supported».

5.2. Конечная точка авторизации

Давайте продолжим наше путешествие с конечной точкой авторизации, отвечающей за поток кода авторизации OAuth 2.0. Он доступен как «authorization_endpoint» в ответе конфигурации OpenID.

Конечная точка:

{{server}}/auth/realms/{{realm}}/protocol/openid-connect/auth?response_type=code\u0026client_id=jwtClient

Более того, эта конечная точка принимает область действия и redirect_uri в качестве необязательных параметров.

Мы не собираемся использовать эту конечную точку в Postman. Вместо этого мы обычно инициируем поток кода авторизации через браузер. Затем Keycloak перенаправляет пользователя на страницу входа, если активный файл cookie для входа отсутствует. Наконец, код авторизации доставляется на URL-адрес перенаправления.

Давайте перейдем к следующему шагу, чтобы узнать, как мы можем получить токен доступа.

5.3. Конечная точка токена

«Конечная точка токена позволяет нам получить токен доступа, токен обновления или токен идентификатора. OAuth 2.0 поддерживает различные типы грантов, например код_авторизации, маркер_обновления или пароль.

Конечная точка токена: {{server}}/auth/realms/{{realm}}/protocol/openid-connect/token

Однако для каждого типа гранта нужны определенные параметры формы.

Давайте сначала проверим конечную точку нашего токена, чтобы получить токен доступа для нашего кода авторизации. Мы должны передать эти параметры формы в теле запроса: client_id, client_secret, grant_type, code и redirect_uri. Конечная точка маркера также принимает область действия в качестве необязательных параметров:

Кроме того, если мы хотим обойти поток кода авторизации, тип предоставления пароля является выбором. Здесь нам нужны учетные данные пользователя, поэтому мы можем использовать этот поток, когда у нас есть встроенная страница входа на наш веб-сайт или в приложение.

Давайте создадим запрос Postman и передадим параметры формы client_id, client_secret, grant_type, имя пользователя и пароль в теле:

Перед выполнением этого запроса мы должны добавить переменные имени пользователя и пароля в ключ/значение среды Postman пары.

Другой полезный тип гранта — refresh_token. Мы можем использовать это, когда у нас есть действительный токен обновления из предыдущего вызова конечной точки токена. Для потока токена обновления требуются параметры client_id, client_secret, grant_type и refresh_token.

Нам нужен ответ access_token для тестирования других конечных точек. Чтобы ускорить тестирование с помощью Postman, мы можем написать скрипт в разделе «Тесты» наших запросов к конечной точке токена:

var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("refresh_token", jsonData.refresh_token);
postman.setEnvironmentVariable("access_token", jsonData.access_token);

5.4. Конечная точка информации о пользователе

Мы можем получить данные профиля пользователя из конечной точки информации о пользователе, если у нас есть действительный токен доступа.

Конечная точка информации о пользователе доступна по адресу: {{server}}/auth/realms/{{realm}}/protocol/openid-connect/userinfo

Давайте создадим для нее запрос Postman и передадим токен доступа в Заголовок Authorization:

Затем выполняем запрос. Вот успешный ответ:

{
    "sub": "a5461470-33eb-4b2d-82d4-b0484e96ad7f",
    "preferred_username": "[email protected]",
    "DOB": "1984-07-01",
    "organization": "baeldung"
}

5.5. Конечная точка Token Introspect

Если серверу ресурсов необходимо убедиться, что токен доступа активен, или ему нужны дополнительные метаданные о нем, особенно для непрозрачных токенов доступа, то конечная точка Token Introspect является ответом. В этом случае сервер ресурсов интегрирует процесс самоанализа с конфигурацией безопасности.

Мы вызываем конечную точку интроспекции Keycloak: {{server}}/auth/realms/{{realm}}/protocol/openid-connect/token/introspect

Давайте создадим запрос интроспекции в Postman, а затем передадим client_id, client_secret и токен в качестве параметров формы:

Если access_token действителен, то мы получаем наш ответ:

{
    "exp": 1601824811,
    "iat": 1601824511,
    "jti": "d5a4831d-7236-4686-a17b-784cd8b5805d",
    "iss": "http://localhost:8083/auth/realms/baeldung",
    "sub": "a5461470-33eb-4b2d-82d4-b0484e96ad7f",
    "typ": "Bearer",
    "azp": "jwtClient",
    "session_state": "96030af2-1e48-4243-ba0b-dd4980c6e8fd",
    "preferred_username": "[email protected]",
    "email_verified": false,
    "acr": "1",
    "scope": "profile email read",
    "DOB": "1984-07-01",
    "organization": "baeldung",
    "client_id": "jwtClient",
    "username": "[email protected]",
    "active": true
}

Однако, если мы используем недопустимый токен доступа, то ответ будет таким:

{
    "active": false
}

6 Заключение

В этой статье с работающим сервером Keycloak мы создали запросы Postman для авторизации, токена, информации о пользователе и конечных точек самоанализа.

Полные примеры запросов Postman, как всегда, доступны на GitHub.

«Доступ к конечным точкам Keycloak с помощью Postman»

Spring на русском

«Доступ к конечным точкам Keycloak с помощью Postman»

«1. Введение

2. OAuth 2.0

3. OpenID C0nnect

4. Keycloak как сервер авторизации

5. Конечные точки Keycloak

5.1. Конечная точка конфигурации OpenID

5.2. Конечная точка авторизации

5.3. Конечная точка токена

5.4. Конечная точка информации о пользователе

5.5. Конечная точка Token Introspect

6 Заключение

Добавить комментарий Отменить ответ