1. введение
В этой статье мы начнем с краткого обзора OAuth 2.0, OpenID и Keycloak. Позже мы узнаем об API-интерфейсах Keycloak REST и о том, как их вызывать в Postman.
2. OAuth 2.0
OAuth 2.0 – это платформа авторизации, которая позволяет аутентифицированному пользователю предоставлять доступ третьим лицам с помощью токенов. Токен обычно ограничен некоторыми областями с ограниченным сроком службы. Таким образом, это безопасная альтернатива учетным данным пользователя.
OAuth 2.0 поставляется с четырьмя основными компонентами:
- Владелец ресурса – конечный пользователь или система, владеющая защищенным ресурсом или данными
- Resource Server – служба предоставляет защищенный ресурс обычно через HTTP-API
- Клиент – вызывает защищенный ресурс от имени владельца ресурса
- Сервер авторизации – выдает токен OAuth 2.0 и доставляет его клиенту после аутентификации владельца ресурса
OAuth 2.0-это протокол с некоторыми стандартными потоками , но здесь нас особенно интересует компонент сервера авторизации.
3. OpenID Connect
OpenID Connect 1.0 (OIDC) построен поверх OAuth 2.0 для добавления уровня управления идентификацией в протокол. Таким образом, он позволяет клиентам проверять личность конечного пользователя и получать доступ к базовой информации профиля через стандартный поток OAuth 2.0. OIDC ввел несколько стандартных областей в OAuth 2.0 , таких как openid , profile и email .
4. Keycloak в качестве сервера авторизации
JBoss разработала Keycloak как Java-решение для управления идентификацией и доступом с открытым исходным кодом. Помимо поддержки OAuth 2.0 и OIDC, он также предлагает такие функции, как посредничество в идентификации, федерация пользователей и SSO.
Мы можем использовать Keycloak как автономный сервер с консолью администратора или встроить его в приложение Spring . Как только мы запустим наш Keycloak любым из этих способов, мы можем попробовать конечные точки.
5. Конечные точки Keycloak
Keycloak предоставляет множество конечных точек REST для потоков OAuth 2.0.
Чтобы использовать эти конечные точки с Postman , давайте начнем с создания среды под названием ” Keycloak “. Затем мы добавляем некоторые записи ключа/значения для URL-адреса сервера авторизации Keycloak, области, идентификатора клиента OAuth 2.0 и пароля клиента:
Затем давайте создадим коллекцию, в которой мы сможем организовать наши тесты Keycloak. Теперь мы готовы исследовать доступные конечные точки.
5.1. Конечная точка конфигурации OpenID
Конечная точка конфигурации подобна корневому каталогу. Он возвращает все другие доступные конечные точки, поддерживаемые области и утверждения, а также алгоритмы подписи .
Давайте создадим запрос в Postman: {{сервер}} /auth/realms/ {{царство}} /.хорошо известная/openid-конфигурация. Почтальон устанавливает значения {{сервер}} и {{царство}} из выбранной среды во время выполнения:
Затем мы выполняем запрос, и если все идет хорошо, у нас есть ответ:
{
"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.
Конечная точка-это:
{{сервер}} /auth/realms/ {{царство}} //protocol/openid-connect/auth?response_type=code&client_id=jwt Client
Кроме того, эта конечная точка принимает scope и redirect_uri в качестве необязательных параметров.
Мы не собираемся использовать эту конечную точку в Postman. Вместо этого мы обычно инициируем поток кода авторизации через браузер. Затем Keycloak перенаправляет пользователя на страницу входа в систему, если активный файл cookie входа недоступен. Наконец, код авторизации доставляется на URL – адрес перенаправления.
Давайте перейдем к следующему шагу, чтобы увидеть, как мы можем получить маркер доступа.
5.3. Конечная точка токена
Конечная точка токена позволяет нам получить токен доступа, токен обновления или токен идентификатора. OAuth 2.0 поддерживает различные типы грантов, такие как authorization_code , refresh_token, или password.
Конечная точка токена: {{сервер}} /auth/realms/ {{царство}} /протокол/openid-connect/токен
Однако каждый тип гранта нуждается в некоторых специальных параметрах формы.
Давайте сначала протестируем нашу конечную точку токена, чтобы получить токен доступа для нашего кода авторизации. Мы должны передать эти параметры формы в теле запроса: client_id , client_secret , grant_type , code и redirect_uri . Конечная точка токена также принимает scope в качестве необязательного параметра:
Более того, если мы хотим обойти поток кода авторизации, то тип password grant является выбором . Здесь нам нужны учетные данные пользователя, поэтому мы можем использовать этот поток, когда у нас есть встроенная страница входа на наш веб-сайт или приложение.
Давайте создадим запрос почтальона и передадим параметры формы client_id , client_secret , grant_type , username и password в теле:
Перед выполнением этого запроса мы должны добавить имя пользователя и пароль переменные для пар ключ/значение среды почтальона.
Еще один полезный тип гранта – refresh_token . Мы можем использовать это, когда у нас есть действительный токен обновления от предыдущего вызова конечной точки токена. Поток токенов обновления требует параметров client_id , client_secret , grant_type и refresh_token .
Нам нужен ответ access_token для тестирования других конечных точек. Чтобы ускорить наше тестирование с Postman, мы можем написать сценарий в разделе Tests наших запросов конечных точек токенов:
var jsonData = JSON.parse(responseBody);
postman.setEnvironmentVariable("refresh_token", jsonData.refresh_token);
postman.setEnvironmentVariable("access_token", jsonData.access_token);5.4. Конечная точка информации о пользователе
Мы можем получить данные профиля пользователя из конечной точки информации пользователя, когда у нас есть действительный маркер доступа.
Конечная точка информации о пользователе доступна по адресу: {{сервер}} /auth/realms/ {{царство}} /протокол/openid-connect/userinfo
Давайте создадим для него запрос Почтальона и передадим токен доступа в заголовок Authorization :
Затем мы выполняем запрос. Вот успешный ответ:
{
"sub": "a5461470-33eb-4b2d-82d4-b0484e96ad7f",
"preferred_username": "[email protected]",
"DOB": "1984-07-01",
"organization": "baeldung"
}5.5. Конечная точка самоанализа токена
Если серверу ресурсов необходимо проверить, активен ли токен доступа или требуется больше метаданных о нем , особенно для непрозрачных токенов доступа , то конечная точка самоанализа токена является ответом. В этом случае сервер ресурсов интегрирует процесс интроспекции с конфигурацией security/|.
Мы называем самоанализ Keycloak конечной точкой: {{сервер}} /auth/realms/ {{царство}} /протокол/openid-connect/токен/интроспекция
Давайте создадим запрос самоанализа в Postman, а затем передадим client_id , client_secret и token в качестве параметров формы:
Если 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 для авторизации, токена, информации о пользователе и конечных точек интроспекции.
Полные примеры запросов почтальонов доступны как всегда на GitHub .