- Red Hat에서 개발한 오픈소스 Identity and Access Management(IAM) 솔루션입니다. 현대적인 애플리케이션과 서비스를 위한 인증 및 권한 부여 기능을 제공하는 인증 서버(Authentication Server)의 기능을 수행합니다.
- Keycloack에서는 여러 플랫폼에서 중앙 집중식 인증 서버로 동작을 합니다. 주요한 기능은 서로 다른 도메인에서 실행되는 애플리케이션 간의 SSO를 지원하거나 REST API 기반에 접근제어 토큰에 대한 인증 제공 및 세션 타임아웃, 동시 로그인 제한과 같은 다양한 세션 기능을 담당합니다.
2) 인증 프로토콜 -1 : SAML(Security Assertion Markup Language) Protocol
💡 인증 프로토콜 -1 : SAML(Security Assertion Markup Language) Protocol
- XML 기반의 개방형 표준 데이터 포맷으로 사용자의 인증 및 인가 데이터를 교환하기 위한 프로토콜입니다. - 주로 기업환경에서 SSO(Single Sign-On)를 구현하는 데 사용되며, 특히 엔터프라이즈 애플리케이션에서 널리 사용됩니다.
구성 요소
설명
간단 설명
Identity Provider(IdP)
- 사용자의 신원을 확인하고 인증을 수행하는 서비스를 의미합니다. - 인증된 사용자의 정보를 SAML Assertions 형태로 SP에게 전달합니다.
- 로그인을 수행하는 시스템 또는 애플리케이션
Service Provider(SP)
- 인증이 완료된 사용자가 이용하는 애플리케이션이나 시스템을 의미합니다. - 인증된 사용자 정보를 받아서 처리하는 주체를 의미합니다.
- 사용자가 최초 접근하는 곳이자 접근 시 IdP로 리다이렉션하여 로그인을 요청하는 시스템 또는 애플리케이션 - Idp에서 로그인 인증 후 접근 권한을 부여받는 시스템
SAML Metadata
- IdP와 SP 간의 신뢰 관계 설정과 통신에 필요한 정보를 담고 있습니다.
- Idp와 SP간에 최초 연결 시, 필요 정보 교환
SAML Assertions
- IdP가 SP에게 전달을 하는 XML 형식의 보안 토큰으로 사용자 인증 상태, 속성 정보, 권한 등의 정보를 포함합니다.
- Idp가 SP에게 전달하는 XML 형식의 보안 토큰
💡 아래의 예시에서는 Keycloak과 SSO 연동시스템 (AWS IAM) 간의 관계를 통해서 이해를 해봅니다. 💡
1. Keycloak이 신원 제공자(Idp, Identity Provider) 역할을 수행하는 경우
💡 Keycloak이 신원 제공자(Idp, Identity Provider) 역할을 수행하는 경우
- 최초 사용자는 AWS IAM 페이지에 접근하면 Keycloak으로 리다이렉션이 됩니다. 리다이렉션 된 Keycloak 로그인 페이지에서 자격증명(아이디/패스워드)를 통해 ‘인증’을 수행하면 AWS IAM으로부터 리소스 접근에 대한 ‘인가’를 부여받아서 AWS 서비스를 이용할 수 있는 경우입니다.
구성 요소
주체
간단 설명
Identity Provider(IdP)
Keycloak
- 로그인을 수행하는 시스템 또는 애플리케이션
Service Provider(SP)
SSO 연동 시스템(AWS IAM)
- 사용자가 최초 접근하는 곳이자 접근 시 IdP로 리다이렉션하여 로그인을 요청하는 시스템 또는 애플리케이션 - Idp에서 로그인 인증 후 접근 권한을 부여받는 시스템
SAML Metadata
- Idp와 SP간에 최초 연결 시, 필요 정보 교환
SAML Assertions
• Idp가 SP에게 전달하는 XML 형식의 보안 토큰
💡 Keycloak이 신원 제공자(Idp, Identity Provider) 역할을 수행할 때 처리과정
1. 서비스 접근 요청 - 사용자는 ‘SSO 연동 시스템 : SP, Service Provider’의 보호된 리소스에 접근을 시도합니다. - 서비스 제공자(SP, Service Provider)는 사용자를 ‘Keycloak 로그인 페이지: IdP, Identity Provider’로 리다이렉트 합니다.
2. 사용자 인증 - Keycloak은 사용자에게 로그인 페이지를 제공합니다. - 사용자는 자격증명(아이디/비밀번호)을 입력하여 인증을 수행합니다
3. SAML Assertion 생성 - 인증이 성공하면 Keycloak은 사용자 정보를 포함한 SAML Assertion을 생성합니다 - 디지털 서명을 통해 Assertion의 무결성을 보장합니다
4. SP로 응답 전송 - Keycloak은 생성된 SAML Assertion을 SSO 연동 시스템에게 전달합니다. - 사용자는 SSO 연동 시스템으로 리다이렉트 되어 서비스를 이용할 수 있게 됩니다
https://blog.logto.io/ko/saml-app-integration
2. Keycloak 서비스 제공자(SP, Service Provider) 역할을 수행하는 경우
💡 Keycloak 서비스 제공자(SP, Service Provider) 역할을 수행하는 경우
- 해당 경우는 사용자는 ‘Keycloak : SP, Service Provider’으로 접근을 시도하면, 해당 Keycloak에서는 ‘외부 SSO 시스템:IdP, Identity Provider’ 로그인 페이지로 리다이렉션 합니다.
- ‘외부 SSO 시스템 로그인 페이지’에서 로그인을 수행하여 ‘인증’을 수행하고 완료가 되면, SSO 연동 서비스는 SAML Assertion을 생성하여 서비스 제공자(SP, Service Provider)로 전송합니다. - Keycloak에서는 SAML Assertion을 검증한 후 사용자에게 접근 권한을 부여합니다.
구성 요소
주체
간단 설명
Identity Provider(IdP)
SSO 연동 시스템(AWS IAM)
- 로그인을 수행하는 시스템 또는 애플리케이션
Service Provider(SP)
Keycloak
- 사용자가 최초 접근하는 곳이자 접근 시 IdP로 리다이렉션하여 로그인을 요청하는 시스템 또는 애플리케이션 - Idp에서 로그인 인증 후 접근 권한을 부여받는 시스템
SAML Metadata
- Idp와 SP간에 최초 연결 시, 필요 정보 교환
SAML Assertions
- Idp가 SP에게 전달하는 XML 형식의 보안 토큰
💡 Keycloak 서비스 제공자(SP, Service Provider) 역할을 수행 처리과정
1. 사용자가 SP에 접근 시도 - 사용자가 보호된 리소스에 접근을 시도합니다 - SP는 사용자가 인증되지 않은 것을 확인합니다 2. IdP로 인증 요청 - SP는 SAML 인증 요청을 생성합니다 - 사용자를 IdP의 로그인 페이지로 리다이렉트 합니다
3. IdP에서 인증 수행 - 사용자는 IdP에서 자격증명을 제공하여 인증합니다 - IdP는 인증 성공 시 SAML Assertion을 생성합니다
4. SP로 응답 처리 - IdP는 사용자를 SP로 다시 리다이렉트 하며 SAML Assertion을 전달합니다 - SP는 받은 SAML Assertion을 검증하고 사용자 세션을 생성합니다 5. 서비스 접근 허용 - 검증이 성공하면 SP는 사용자에게 요청한 리소스에 대한 접근을 허용합니다
https://blog.logto.io/ko/saml-app-integration
3. SAML 처리 상세 과정 -1 : SAML 메타데이터 교환
💡 SAML 처리 상세 과정 -1 : SAML 메타데이터 교환
- SAML 2.0 프로토콜을 통한 안전한 인증 정보 교환 설정하며 Keycloak과 AWS 간의 신뢰 관계 구축을 위한 기초 설정을 합니다.
- 인증(Authentication)은 자격증명을 통해서 사용자가 자신이 주장하는 신원이 맞는지 확인하는 과정을 의미합니다. - 즉, “당신이 누구인지”에 대해 확인하는 절차를 의미합니다.
- 인가(Authorization)는 인증과정을 통해 인증된 사용자에게 권한을 부여하는 과정을 의미합니다. - 즉, 리소스에 접근하여 “무엇을 할 수 있는지”에 대해 권한을 부여하는 절차를 의미합니다.
💡 OAuth 2.0 내에는 인증기능이 없는가?
- 아래의 이미지는 OAuth2.0의 인증 프로세스입니다. - 아래의 프로세스를 확인해 보면, 사용자는 애플리케이션을 통해 로그인을 수행하여 자격증명(아이디/비밀번호)을 통해서 “내가 누구인지”에 대한 인증을 수행합니다. - 이러한 인증 과정을 통해서, 최종적으로 Access Token을 발급받아서, 리소스에 대한 접근 권한을 부여받는 인가 과정이 수행이 됩니다. - 이렇듯, OAuth2.0에서는 인증과 인가를 수행하지만 “인가”자체에만 초점을 맞추고 있고, 인증 방식에 대한 명확한 표준 방법이 정의되지 않았습니다. - 그렇기에 인증 과정의 표준화된 방법이 필요하게 되었고, 이를 해결하기 위해 OIDC가 등장하게 되었습니다.
- OIDC(OpenID Connect) 인증 프로토콜을 이용하여 구현하는 구체적인 인증 방법들을 의미합니다. 즉, 애플리케이션(Client)을 기준으로 OIDC 프로토콜을 통해서 Keycloak과 통신하고 인증하는 방법들을 의미합니다. - 이러한 OIDC 인증 흐름은 한 가지 방법으로 인증 과정을 수행할 수 있고, 여러 가지 다양한 방법으로 인증과정을 구현할 수 있습니다.
1. 주요 특징
주요 특징
설명
유연한 구성
다양한 인증 방식을 조합하여 커스텀 인증 흐름을 만들 수 있습니다.
다중 인증
여러 단계의 인증을 순차적으로 적용할 수 있습니다.
조건부 실행
특정 조건에 따라 다른 인증 단계를 실행할 수 있습니다.
[ 더 알아보기 ]
💡 그러면 keycloak에서 설정한 flow를 통해서 단일 인증 외에 다중 인증으로 처리가 가능하다는 걸까?
- Keycloak의 Authentication Flow 설정을 통해 다중 인증 구성이 가능합니다. - 예를 들어서, 자격증명(아이디/비밀번호)을 통해서 로그인 사용자의 인증을 수행하고 다음 단계로 OTP(One-Time Password) 인증을 수행할 수 있습니다. - 이러한 과정을 통해서 인증 단계를 순차적으로 실행이 가능하고, 필수/선택적 인증 단계 설정이 가능합니다.
5) 인증 흐름(Authentication flow) 종류
인증 흐름 종류
설명
사용처
Standard Flow
- OAuth 2.0의 Authorization Code Flow 기반으로 인증을 수행하며, 사용자는 Keycloak 로그인 페이지로 리다이렉트 되어서 인증을 수행하는 인증방식을 의미합니다.
웹 애플리케이션
Direct Access Grants
- 직접 REST API를 통해 자격 증명(아이디/비밀번호)을 담아서 통신하며 별도의 리다이렉션 없이 즉시 토큰을 받을 수 있는 인증방식을 의미합니다.
신뢰할 수 있는 애플리케이션(모바일 애플리케이션, 백엔드 시스템에서 직접 인증이 필요한 경우)
Implicit Flow
- 간소화된 인증흐름으로 인가 코드(Auth Code) 없이 직접 액세스 토큰을 받아서 인증을 수행하는 방식을 의미합니다.
모바일 앱, 단일 페이지 애플리케이션(SPA)
Service Accounts Roles
- 애플리케이션 시스템 간에 인증 기반의 통신을 위한 방법으로, 클라이언트 자체적으로 API를 호출하여 다른 서비스와의 통신을 할 때 사용하는 인증방식입니다.
마이크로서비스 간 통신(서버-서버간 통신), 자동화된 프로세스
OAuth 2.0 Device Authorization Grant
- 스마트 TV나 IoT 기기와 같이 제한된 입력 기능을 가진 디바이스를 위한 인증 방식입니다.
스마트 TV 애플리케이션, IoT 디바이스, 게임 콘솔, 프린터 및 스캐너
OIDC CIBA Grant
- 클라이언트가 사용자의 직접적인 상호작용 없이 인증을 시작하는 인증 방식입니다. - 사용자가 인증을 요청한 디바이스와 실제 인증을 수행하는 디바이스가 물리적으로 분리된 방식입니다.
금융 서비스, 공유 디바이스, 스마트홈 시스템
💡 [참고] Keycloak내에 Client를 설정할 때, OIDC를 선택한 경우 인증 흐름(Authentication flow)을 선택하여 인증 방식을 지정합니다.
💡 [참고] OAuth 2.0의 인증방식에 대해 궁금하시면 아래의 글을 참고하시면 도움이 됩니다.
💡 Standard flow - OAuth 2.0의 Authorization Code Flow를 기반으로 하는 가장 일반적이고 안전한 인증 방식을 의미하며, 주로 웹 애플리케이션에서 주로 사용되는 방식입니다. - 해당 방식은 OAuth 2.0을 기반으로 하여 동작 방식은 비슷하지만, OIDC(OpenID Connect) 프로토콜이 추가되어서 인증(Authentication) 기능이 강화되었습니다.
https://blog.pages.kr/2839
1.1. Authorization Code Flow : OAuth 2.0 처리 방식
💡 Authorization Code Flow : OAuth 2.0 처리 방식
- Standard flow 방식은 OAuth 2.0의 처리 방식인 Authorization Code Flow 방식을 기반으로 구현되었기에 우선적으로 처리과정을 알아봅니다. - 사용자는 자격인증(아이디/비밀번호 기반 로그인)을 통해서 인증코드(Authorization Code)를 먼저 발급받고, 이 인증코드를 기반으로 접근 토큰을 발급받아서 리소스에 접근이 하는 이중 접근 방식을 취합니다.
- OAuth 2.0의 Authorization Code Flow와 비교하였을 때, 접근 권한(Authorization)에 중점을 두어 액세스 토큰만 반환하지만 Standard flow의 경우는 액세스 토큰과 함께 ID 토큰도 반환하여 사용자 인증 정보를 제공합니다. - 또한, Authorization Code Flow의 경우는 주로 리소스 접근 권한 부여에 대해 초점이 맞춰져 있지만, Standard flow의 경우는 사용자 인증(Authentication)과 권한 부여(Authorization)를 모두 처리합니다.
💡 Standard flow 상세 처리 과정 1. 로그인 (Login) - 사용자가 클라이언트 애플리케이션에서 로그인을 시도하는 단계입니다. - 예를 들어서, 사용자는 로그인 페이지를 클릭하는 단계입니다.
2. 인증 요청 생성(Generate authentication request) - 클라이언트가 client_id, redirect_uri, scope 등의 필요한 파라미터를 포함한 인증 요청을 생성합니다.
3. Keycloak으로 리다이렉트(Redirect to Keycloak) - 클라이언트가 사용자를 Keycloak의 인증 엔드포인트로 리다이렉트 시킵니다.
4. Keycloak으로 인증 요청 전송 (Send authentication request to Keycloak) - 생성된 인증 요청이 Keycloak 서버로 전송됩니다. - 해당 단계에서는 실제 Keycloak에서 구성한 로그인 페이지가 사용자에게 표시되는 단계입니다.
5. 사용자 인증(Authenticate user) - 사용자가 Keycloak의 로그인 페이지에서 자신의 자격 증명을 입력하여 인증을 수행합니다. - 해당 단계에서 사용자는 keycloak에서 구성한 로그인 페이지로 자격 증명(아이디/패스워드)을 입력하여 로그인을 수행하는 단계입니다. 6. 인가 코드 반환(Return authorization code) - 인증이 성공적으로 완료되면, Keycloak은 인가 코드를 생성하여 클라이언트의 리다이렉트 URI로 전송합니다. - 해당 단계에서는 로그인이 성공하고, 인가코드(AuthCode)를 발급받습니다.
7. Keycloak으로 토큰 요청 전송(Send token request to Keycloak) - 클라이언트는 받은 인가 코드를 사용하여 Keycloak의 토큰 엔드포인트에 액세스 토큰을 요청합니다. - 해당 단계에서는 이전 단계에서 발급받은 인가코드(AuthCode)를 기반으로 Access Token을 요청하며, 최종적으로 사용자에게 반환이 됩니다.
1.3. Direct Access Grants, Implicit Flow 방식보다 Standard Flow 방식이 보안성이 높은 이유는?
💡 Direct Access Grants, Implicit Flow 방식보다 Standard Flow 방식이 보안성이 높은 이유는?
1. 토큰 발급의 이중 단계 처리 & 토큰 교환 시 추가 인증
- Standard flow 방식에서는 다른 방식과 달리 두 단계로 토큰을 발급받습니다. - 첫 번째로, 인가 코드(Authorization Code)를 발급받고, 이를 통해서 최종적으로 접근 토큰(Access Token)을 발급받는 두 단계로 진행됩니다. - 인가 코드는 임시적이고 짧은 수명을 가지며, 중간에 탈취되더라도 실제 Access Token을 얻기 위해서는 client secret 정보가 추가로 필요하기 때문에 보안이 한층 강화됩니다.
- 반대로 Implicit Flow의 경우는 접근 토큰(Access Token)이 URL 파라미터로 전달되어 브라우저 히스토리나 로그에 노출될 수 있는 위험이 있습니다.
2. 백 채널 통신
- 서버-서버 간 통신으로 이루어지기 때문에 중요한 정보가 브라우저에 노출되지 않습니다. - 프런트엔드 환경에서 토큰이 직접 노출되는 것을 방지할 수 있습니다. - 예를 들어서, 사용자는 프런트엔드에서 로그인을 합니다. 이 로그인 정보를 기반으로 백엔드 서버가 Keycloak 서버와 직접 통신하여 인증 코드를 받습니다. 그리고 이 발급받은 인증코드를 사용하여 백엔드 서버가 다시 Keycloak과 통신하여 Access Token을 받아와 최종적으로 클라이언트 백엔드가 프런트엔드에 필요한 정보를 안전하게 전달합니다.
- 반대로 Direct Access Grants의 경우는 사용자의 자격증명(아이디/패스워드)이 클라이언트에 직접 노출되는 위험이 있습니다.
3. 인증 단계 분리
- 사용자 인증(로그인) 단계와 토큰 발급 단계가 명확히 구분되어 있습니다. 그리고 각 단계마다 독립적인 보안 검증이 가능하기에 문제 발생 시 다음 단계로 진행되지 않습니다. - 단계가 분리가 되어서 인증 실패와 토큰 발급 실패를 분리하여 추적이 가능하며, 각 단계별로 다른 보안 정책을 적용할 수 있습니다.
- 반대로 Direct Access Grants의 경우는 분리가 되어 있지 않은 단일 단계를 통해서, 통신 즉시 토큰을 발급이 되어서 노출 위험이 있습니다.
2. Direct Access Grants
💡 Direct Access Grants - REST API를 통해 직접 토큰을 요청하는 방식으로 사용자의 자격 증명(아이디/비밀번호)을 포함하여 요청하며, 별도의 리다이렉션 없이 즉시 토큰을 받을 수 있는 인증 방식을 의미합니다. - 사용자의 자격 증명이 클라이언트 애플리케이션에 직접 노출되므로 신뢰할 수 있는 애플리케이션에서만 사용해야 합니다.
💡 [참고] 공식 사이트 내에 직접 REST API를 통해서 Keycloak과 통신하여 토큰을 반환받는 엔드포인트입니다.
- 클라이언트 애플리케이션은 사용자로부터 아이디와 비밀번호를 직접 수집합니다. - 일반적으로 애플리케이션의 로그인 폼(application/x-www-form-urlencoded Content-Type)을 통해 입력받습니다
2. 토큰 요청
- 클라이언트는 수집한 자격증명을 Keycloak 토큰 엔드포인트로 직접 전송합니다. - 예를 들어, 로컬 9001 포트에 구성한 Keycloak의 Realm에 [POST] http://localhost:9001/realms/dev-realm/protocol/openid-connect/token 엔드포인트로 요청합니다. - 요청 로그인 폼으로는 grant_type, client_id, client_secret, username, password을 포함시켜서 전송합니다. - [참고] 해당 URL을 참고하시면 해당 API 엔드포인트 정보를 확인할 수 있습니다. https://www.keycloak.org/securing-apps/oidc-layers
3. 자격증명 검증 - Keycloak 서버는 전달받은 사용자 자격증명의 유효성을 검증합니다 - 클라이언트 인증정보(client_id, client_secret)도 함께 확인합니다
4. 토큰 발급
- 검증이 성공하면 Keycloak은 즉시 액세스 토큰을 발급합니다 - 응답으로 access_token, refresh_token, token_type 등이 포함된 JSON을 반환합니다
5. 토큰 사용 - 클라이언트는 발급받은 액세스 토큰을 사용하여 보호된 리소스에 접근할 수 있습니다 - Authorization 헤더에 Bearer 토큰을 포함시켜 API 요청을 수행합니다
💡 [참고] Postman을 통해서 Keycloak 엔드포인트로 호출을 하면 아래와 같이 즉시 access_token, refresh_token을 반환받을 수 있습니다.
[ 더 알아보기 ] 💡 Direct Access Grants는 보안적으로 취약하지 않은가?
- 사용자의 아이디와 비밀번호가 클라이언트 애플리케이션에 직접 노출되기에 자격증명 노출의 위험이 있습니다. 또한 신뢰할 수 없는 클라이언트에서 사용할 경우 자격증명 탈취 위험이 있습니다. - HTTPS를 반드시 사용해야 하며, 네트워크 구간에서 자격증명이 안전하게 전송되어야 합니다. 전송 보안에서 중간자 공격(Man-in-the-Middle) 위험이 있을 수 있습니다. - 가능하면 Standard Flow와 같은 더 안전한 인증 방식을 사용하는 것이 권장됩니다
3. Implicit Flow
💡 Implicit Flow - OAuth 2.0의 인증 방식 중 하나로, 클라이언트 사이드 애플리케이션에서 사용되는 단순화된 인증 흐름입니다. - Standard flow 방식과 다르게 인가 코드 없이 바로 액세스 토큰을 받는 방식입니다.
3.1. Implicit Flow 처리 과정
💡 Implicit Flow 처리 과정 1. 사용자 로그인 시도 - 사용자가 로그인을 시도할 때, Keycloak의 로그인 페이지로 리다이렉트 되어 자격증명(아이디/패스워드)을 입력 요청을 합니다.
2. 로그인 성공 - 사용자가 로그인을 성공하면, 바로 액세스 토큰을 리다이렉트 URL로 전달이 됩니다.
3. 토큰 사용 - 사용자는 전달받은 액세스 토큰을 통해서 리소스에 접근합니다.
https://blog.pages.kr/2839
[ 더 알아보기 ] 💡 Standard flow 방식보다 단순화된 방식 같은데 보안적으로 취약하지는 않을까?
- 액세스 토큰이 URL 파라미터로 전달되어 브라우저 히스토리나 로그에 노출될 위험이 있습니다. 또한 인가 코드 단계가 생략되어 토큰 탈취에 대한 위험이 높습니다. - 그리고 Refresh Token을 안전하게 저장하기 어려워 일반적으로 지원되지 않습니다. 이러한 보안상의 이유로 현대의 OAuth 2.0 구현에서는 Implicit Flow 대신 PKCE(Proof Key for Code Exchange)를 추가한 Authorization Code Flow를 권장합니다.
💡 PKCE(Proof Key for Code Exchange)는 뭘까?
- 주로 모바일 앱이나 Single Page Application(SPA)과 같은 공개 클라이언트에서 인증 코드 가로채기 공격을 방지하기 위해 사용됩니다. - Authorization Code Flow에 추가적인 보안 계층을 제공합니다.
4. Service Accounts Roles
💡 Service Accounts Roles
- 서비스 계정(Service Accounts)에 할당할 수 있는 권한과 역할을 정의하고 이를 기반으로 Client Credentials Flow 방식을 통해 실제 토큰을 발급받아 인증하는 방식을 의미합니다. 이렇게 발급된 토큰에는 해당 서비스 계정에 부여된 권한 정보 및 역할이 포함되어 있어서, 서비스는 자신에게 허용된 범위 내에서만 리소스에 접근할 수 있습니다.
- 여기서 서비스 계정(Service Accounts)은 사용자 자체가 아닌 애플리케이션이나 서비스가 고유하게 가지고 있는 계정을 의미합니다. 각각의 서비스 계정은 특정 역할(Role)과 권한을 가질 수 있습니다. 또한, 서비스 별로 접근 제어(읽기, 쓰기, 삭제, 관리자 권한 등)를 가질 수 있습니다.
- 예를 들어서, 서비스 계정 A, B가 있고, 서비스 계정 A은 서비스 계정 B로 접근할 수 있다는 권한이 할당되었다고 가정하에 있습니다. 그렇게 되면 서비스 계정 A에서 계정 B로 접근할 때 발급받은 토큰을 통해서 인증하여 접근할 수 있습니다. 이는 토큰 내에 서비스 계정에 대한 권한 정보와 역할이 포함되어서 리소스에 대한 접근이 가능합니다.
- 자동화된 프로세스, 배치 작업, 마이크로서비스 간 통신 등에 활용됩니다.
4.1. Client Credentials Flow
💡 Client Credentials Flow
- Service Account가 실제로 인증을 수행할 때 사용하는 인증 방식을 의미합니다. 즉, Service Accounts Roles에서는 클라이언트에 할당할 수 있는 역할과 권한을 정의하며, Client Credentials Flow에서는 Service Accounts가 실제로 인증을 수행할 때 사용하는 인증방식을 의미합니다.
💡 Client Credentials Flow
1. 클라이언트 ID와 시크릿으로 액세스 토큰 요청 (Request access token for client ID and secret) - 클라이언트가 자신의 ID와 시크릿을 사용하여 인증 서버에 액세스 토큰을 요청합니다.
2. 액세스 토큰 발급(Granted access token) - 인증 서버는 클라이언트의 자격 증명을 확인하고 유효한 경우 액세스 토큰을 발급합니다.
3. 액세스 토큰으로 API 요청(API request with the access token) - 클라이언트는 발급받은 액세스 토큰을 사용하여 보호된 리소스에 API 요청을 합니다.
4. API 응답(API response) - 리소스 서버는 토큰을 검증하고 요청된 리소스에 대한 응답을 반환합니다.
4.2. Service Accounts Roles + Client Credentials Flow 방식 처리 과정
💡 Service Accounts Roles 처리과정
1. 클라이언트 등록 및 설정 - Keycloak 관리 콘솔에서 클라이언트를 등록하고 Service Account Roles를 활성화하여 사용합니다. - Assign role 버튼을 눌러서 필요한 역할(roles)과 권한을 클라이언트에 할당하여 설정합니다.
2. 클라이언트 인증 : Client Credentials Flow 방식 - 클라이언트 ID와 클라이언트 시크릿을 사용하여 인증합니다. - grant_type=client_credentials 파라미터로 토큰 엔드포인트에 요청합니다,
3. 토큰 발급 : Client Credentials Flow 방식 - Keycloak은 클라이언트 자격 증명을 검증합니다. - 유효한 경우 액세스 토큰 발급 (할당된 역할과 권한 정보 포함)합니다.
4. API 호출 - 발급받은 액세스 토큰으로 보호된 리소스에 접근합니다. - 토큰에 포함된 권한 범위 내에서만 API 호출 가능하며 사용자가 아닌 서비스 계정 콘텍스트로 동작
5. OAuth 2.0 Device Authorization Grant
💡 OAuth 2.0 Device Authorization Grant
- 입력 기능이 제한된 디바이스(IoT 기기, 스마트 TV)와 같은 디바이스에서 사용되는 인증 방식을 의미합니다. - 사용자는 디바이스로부터 제공받은 사용자 코드와 함께 검증 URL을 다른 기기에서 입력함으로써 간편하게 인증을 완료할 수 있습니다. - 스마트 TV 애플리케이션, IoT 디바이스, 게임 콘솔, 프린터 및 스캐너 등에서 사용합니다.
5.1. Device Authorization Grant 처리 과정
💡 Device Authorization Grant 처리 과정 1. 디바이스 코드 요청(Device Code Request) - 사용자가 로그인 페이지로 접근하게 되면 Device Authorization 엔드포인트로 인증 요청을 하게 됩니다. - 이 과정에서 verification_uri와 user_code를 생성하여서 검증 URL 혹은 QR 코드, 일반 코드를 생성합니다.
2. 디바이스의 폴링 (Poll with Device Code) - 디바이스는 주기적으로 Keycloak의 토큰 엔드포인트에서 device_code를 사용하여서 폴링을 수행합니다. - 해당 폴링 과정은 클라이언트가 서버로 주기적으로 요청을 보내서 상태 변경이나 새로운 데이터를 확인하는 과정을 의미합니다.- 즉, Keycloak은 사용자 인증이 완료될 때까지 수행합니다.
3. 사용자 코드 검증 및 인증(Access verification URL Enter User Code) - 사용자는 디바이스에 표시된 검증 URL을 다른 기기(예: 스마트폰, 컴퓨터)에서 방문합니다. - 검증 URL 페이지에서 디바이스에 표시된 user_code를 입력합니다. - Keycloak은 입력된 user_code의 유효성을 검증합니다. user_code가 유효한 경우, 사용자는 일반적인 로그인 절차를 진행합니다.
4. 접근 토큰 발급 (Response 200 with Access Token) - 사용자 인증 완료 시, Keycloak은 디바이스의 다음 폴링 요청에 액세스 토큰 발급합니다. 발급된 토큰에는 Keycloak에서 설정된 권한과 역할 정보가 포함됨
6. OIDC CIBA(Connect Client-Initiated Backchannel) Grant
💡 OIDC CIBA(Connect Client-Initiated Backchannel) Grant
- OpenID Connect의 확장 기능으로, 클라이언트가 사용자의 직접적인 상호작용 없이 인증을 시작할 수 있게 해주는 인증 방식입니다. - 사용자가 인증을 요청한 디바이스(예: ATM, 웹사이트)와 실제 인증이 이루어지는 디바이스(예: 스마트폰)가 물리적으로 분리되어 있습니다. - 이는 백 채널(서버 간 통신)을 통해서 이루어지는 특징을 가지고 있습니다.
- 주로 금융거래 승인, 기업 보안 시스템, 의료 정보시스템과 같은 경우에 사용이 됩니다. 예를 들어서, 금융거래 승인 부분에서 사용자가 ATM에서 현금을 인출을 시도할 때, 은행 앱으로 푸시 알림을 보내 승인을 요청합니다.
