기능: OAuth 2.0의 Authorization Code 흐름을 구현한 방식으로, 가장 범용적이고 안전한 인증 방식이다.
작동 방식:
1. 사용자가 애플리케이션에 접근 요청 시 Keycloak의 로그인 페이지로 리다이렉트
2. 로그인 성공 후 애플리케이션에 인증 코드를 전달하고, 이 코드를 통해 Access Token과 Refresh Token을 발급
활성화 시기:
기능: Resource Owner Password Credentials Grant라고도 불리며, 사용자 ID와 비밀번호를 직접 API로 전송하여 인증하는 방식이다.
작동 방식:
1. 사용자의 자격 증명(아이디/비밀번호)을 애플리케이션이 직접 수집하여 Keycloak에 전송
2. 유효한 자격 증명인 경우 Keycloak이 토큰을 직접 발급
활성화 시기:
기능: 브라우저 기반 애플리케이션을 위한 간소화된 OAuth 2.0 흐름이다.
작동 방식:
1. 인증 코드 단계 없이 직접 액세스 토큰을 브라우저로 전달
2. URL 프래그먼트(#)를 통해 토큰이 전달됨
활성화 시기:
기능: 클라이언트가 자체 자격 증명으로 직접 토큰을 요청하는 방식이다(Client Credentials Grant).
작동 방식:
1. 사용자 개입 없이 클라이언트ID와 시크릿만으로 토큰 획득
2. 서비스 계정에 특정 역할을 부여하여 접근 권한 관리
활성화 시기:
기능: 브라우저나 복잡한 입력 인터페이스가 없는 장치를 위한 인증 방식이다.
작동 방식:
1. 장치에 사용자 코드와 확인 URI를 표시
2. 사용자가 다른 기기에서 해당 URI에 접속하여 표시된 코드를 입력하고 인증
3. 장치는 백그라운드에서 주기적으로 인증 상태를 확인하여 토큰 획득
활성화 시기:
기능: Client Initiated Backchannel Authentication Flow로, 사용자 인증과 토큰 발급 과정이 분리되어 있는 인증 방식이다.
작동 방식:
1. 클라이언트가 사용자 식별자로 인증 요청을 Keycloak에 전송
2. Keycloak은 별도의 인증 장치(스마트폰 등)를 통해 사용자에게 인증 요청
3. 사용자가 인증 장치에서 인증을 완료하면 클라이언트는 토큰을 발급받음
활성화 시기:
| 인증 흐름 | 활성화 여부 | 사용 이유 및 설명 |
|---|---|---|
| Standard flow (Authorization Code + PKCE) | ON | 모바일/웹 앱(Flutter)에서 안전하게 인증 처리. PKCE 적용시 인증 코드 탈취 위험 감소 |
| Direct access grants | 필요시 | 앱에서 ID/비밀번호 직접 전송 필요시(예: 자체 백엔드 통신). 보안상 일반적 비권장 |
| Implicit flow | OFF | 보안 취약점으로 인해 폐기됨. Authorization Code + PKCE로 대체 |
| Service accounts roles | 필요시 | 서버-서버(Quarkus API ↔ Keycloak) 통신 등 사용자 개입 없는 시스템 간 인증 필요시 활성화 |
| OAuth 2.0 Device Authorization Grant | OFF | IoT/TV/CLI 등 특수 장치가 아닌 일반 앱 환경에서는 불필요 |
| OIDC CIBA Grant | OFF | 금융 등 별도 인증 장치가 필요한 특수케이스 제외하고 일반 앱 환경에서는 사용하지 않음 |