1. 소개
이 기사에서는 OAuth 2.0, OpenID 및 Keycloak에 대한 빠른 검토로 시작합니다. 그런 다음 Keycloak REST API와 Postman에서 호출하는 방법에 대해 알아보겠습니다.
2. OAuth 2.0
OAuth 2.0 은 인증된 사용자가 토큰을 통해 제3자에게 액세스 권한을 부여할 수 있는 권한 부여 프레임워크입니다. 토큰은 일반적으로 수명이 제한된 일부 범위로 제한됩니다. 따라서 사용자 자격 증명에 대한 안전한 대안입니다.
OAuth 2.0에는 네 가지 주요 구성 요소가 있습니다.
- 리소스 소유자 – 보호된 리소스 또는 데이터를 소유하는 최종 사용자 또는 시스템
- 리소스 서버 – 서비스는 일반적으로 HTTP 기반 API를 통해 보호된 리소스를 노출합니다.
- 클라이언트 – 리소스 소유자를 대신하여 보호된 리소스를 호출합니다.
- Authorization Server – OAuth 2.0 토큰을 발급하고 리소스 소유자를 인증한 후 클라이언트에 전달합니다.
OAuth 2.0은 몇 가지 표준 흐름 이 있는 프로토콜 이지만 여기서는 특히 인증 서버 구성 요소에 관심이 있습니다.
3. 오픈아이디 커넥트
OpenID Connect 1.0 (OIDC)은 OAuth 2.0 위에 구축되어 프로토콜에 ID 관리 계층을 추가합니다. 따라서 클라이언트는 표준 OAuth 2.0 흐름을 통해 최종 사용자의 ID를 확인하고 기본 프로필 정보에 액세스할 수 있습니다. OIDC는 openid , profile , email 과 같은 몇 가지 표준 범위를 OAuth 2.0에 도입했습니다 .
4. 인증 서버로서의 Keycloak
JBoss는 Java 기반 오픈 소스 ID 및 액세스 관리 솔루션으로 Keycloak 을 개발 했습니다 . OAuth 2.0 및 OIDC를 모두 지원하는 것 외에도 ID 중개, 사용자 연합 및 SSO와 같은 기능도 제공합니다.
Keycloak을 관리 콘솔이 있는 독립형 서버 로 사용 하거나 Spring 애플리케이션에 포함할 수 있습니다 . 이러한 방법 중 하나로 Keycloak을 실행하면 끝점을 시도할 수 있습니다.
5. Keycloak 엔드포인트
Keycloak은 OAuth 2.0 흐름에 대한 다양한 REST 끝점을 노출합니다.
Postman 과 함께 이러한 끝점을 사용하려면 " Keycloak " 이라는 환경을 만드는 것으로 시작하겠습니다 . 그런 다음 Keycloak 인증 서버 URL, 영역, OAuth 2.0 클라이언트 ID 및 클라이언트 비밀번호에 대한 몇 가지 키/값 항목을 추가합니다.
그런 다음 Keycloak 테스트를 구성할 수 있는 컬렉션을 만들어 보겠습니다. 이제 사용 가능한 끝점을 탐색할 준비가 되었습니다.
5.1. OpenID 구성 끝점
구성 끝점은 루트 디렉터리와 같습니다. 다른 모든 사용 가능한 끝점, 지원되는 범위 및 클레임, 서명 알고리즘을 반환합니다 .
Postman에서 요청을 생성해 보겠습니다. {{server}} /auth/realms/ {{realm}} /.well-known/openid-configuration. Postman은 런타임 중에 선택한 환경에서 {{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 Code Flow를 담당하는 엔드포인트를 인증하는 여정을 계속해 보겠습니다 . OpenID 구성 응답에서 "authorization_endpoint" 로 사용할 수 있습니다 .
끝점은 다음과 같습니다.
{{서버}} /auth/realms/ {{realm}} /protocol/openid-connect/auth?response_type=code&client_id=jwtClient
또한 이 끝점은 선택 매개 변수로 범위 와 redirect_uri 를 허용 합니다.
우리는 Postman에서 이 끝점을 사용하지 않을 것입니다. 대신 일반적으로 브라우저를 통해 인증 코드 흐름을 시작합니다. 그런 다음 Keycloak은 활성 로그인 쿠키를 사용할 수 없는 경우 사용자를 로그인 페이지로 리디렉션합니다. 마지막으로 인증 코드가 리디렉션 URL로 전달됩니다.
다음 단계로 이동하여 액세스 토큰을 얻는 방법을 살펴보겠습니다.
5.3. 토큰 엔드포인트
토큰 끝점을 사용하면 액세스 토큰, 새로 고침 토큰 또는 ID 토큰을 검색할 수 있습니다. OAuth 2.0은 authorization_code , refresh_token 또는 비밀번호 와 같은 다양한 권한 부여 유형을 지원 합니다.
토큰 엔드포인트: {{server}} /auth/realms/ {{realm}} /protocol/openid-connect/token
그러나 각 부여 유형에는 전용 양식 매개변수가 필요합니다.
먼저 토큰 엔드포인트를 테스트하여 인증 코드에 대한 액세스 토큰을 얻습니다. 요청 본문에서 이러한 양식 매개변수를 전달해야 합니다. client_id , client_secret , grant_type , code 및 redirect_uri . 토큰 끝점은 또한 범위 를 선택적 매개 변수로 허용합니다 .
또한 인증 코드 흐름을 우회하려면 암호 부여 유형이 선택 됩니다. 여기에 사용자 자격 증명이 필요하므로 웹 사이트나 애플리케이션에 로그인 페이지가 내장되어 있을 때 이 흐름을 사용할 수 있습니다.
Postman 요청을 만들고 본문에 client_id , client_secret , grant_type , username 및 password 양식 매개변수를 전달해 보겠습니다 .
이 요청을 실행하기 전에 사용자 이름 과 암호 변수를 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": "john@test.com",
"DOB": "1984-07-01",
"organization": "baeldung"
}5.5. 토큰 인트로스펙트 엔드포인트
리소스 서버가 액세스 토큰이 활성 상태인지 확인해야 하거나 특히 불투명한 액세스 토큰의 경우 이에 대한 추가 메타데이터가 필요한 경우 토큰 검사 엔드포인트가 답입니다. 이 경우 리소스 서버는 내부 검사 프로세스를 Security 구성 과 통합합니다 .
우리는 Keycloak의 내부 엔드포인트를 {{server}} /auth/realms/ {{realm}} /protocol/openid-connect/token/introspect 라고 부릅니다.
Postman에서 introspect 요청을 만든 다음 client_id , client_secret 및 토큰 을 양식 매개변수로 전달해 보겠습니다 .
는 IF 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": "john@test.com",
"email_verified": false,
"acr": "1",
"scope": "profile email read",
"DOB": "1984-07-01",
"organization": "baeldung",
"client_id": "jwtClient",
"username": "john@test.com",
"active": true
}그러나 유효하지 않은 액세스 토큰을 사용하는 경우 응답은 다음과 같습니다.
{
"active": false
}6. 결론
이 기사에서는 Keycloak Server를 실행하여 권한 부여, 토큰, 사용자 정보 및 인트로스펙트 엔드포인트에 대한 Postman 요청을 생성했습니다.
