Keycloak Authentication Flow

koonlx·2025년 5월 19일

Keycloak

목록 보기
1/2
post-thumbnail

1. Keycloak의 인증 흐름(Authentication Flow) 유형 및 활용 가이드

Standard flow

기능: OAuth 2.0의 Authorization Code 흐름을 구현한 방식으로, 가장 범용적이고 안전한 인증 방식이다.
작동 방식:
1. 사용자가 애플리케이션에 접근 요청 시 Keycloak의 로그인 페이지로 리다이렉트
2. 로그인 성공 후 애플리케이션에 인증 코드를 전달하고, 이 코드를 통해 Access Token과 Refresh Token을 발급

활성화 시기:

  • 웹 브라우저 기반 애플리케이션(일반 웹사이트, SPA 등)에서 사용자 인증이 필요할 때
  • 보안성이 중요한 애플리케이션에서 권장되는 기본 인증 방식

Direct access grants

기능: Resource Owner Password Credentials Grant라고도 불리며, 사용자 ID와 비밀번호를 직접 API로 전송하여 인증하는 방식이다.
작동 방식:
1. 사용자의 자격 증명(아이디/비밀번호)을 애플리케이션이 직접 수집하여 Keycloak에 전송
2. 유효한 자격 증명인 경우 Keycloak이 토큰을 직접 발급
활성화 시기:

  • 모바일 앱과 같이 브라우저로 리다이렉트하기 어려운 환경
  • 자체 개발한 애플리케이션처럼 신뢰할 수 있는 클라이언트에서만 사용
  • REST API 인증이 필요한 경우

Implicit flow

기능: 브라우저 기반 애플리케이션을 위한 간소화된 OAuth 2.0 흐름이다.
작동 방식:
1. 인증 코드 단계 없이 직접 액세스 토큰을 브라우저로 전달
2. URL 프래그먼트(#)를 통해 토큰이 전달됨
활성화 시기:

  • 레거시 단일 페이지 애플리케이션(SPA)에서 사용
  • 보안상의 이유로 현재는 사용이 권장되지 않음
  • Standard flow를 대체 사용할 수 없는 특수한 경우에만 제한적으로 활용

Service accounts roles

기능: 클라이언트가 자체 자격 증명으로 직접 토큰을 요청하는 방식이다(Client Credentials Grant).
작동 방식:
1. 사용자 개입 없이 클라이언트ID와 시크릿만으로 토큰 획득
2. 서비스 계정에 특정 역할을 부여하여 접근 권한 관리
활성화 시기:

  • 백그라운드 서비스, 마이크로서비스 간 통신
  • 사용자 컨텍스트 없이 시스템 간 API 통신이 필요한 경우
  • 클라이언트 인증 설정에서 ‘Service Accounts Enabled’를 ON으로 설정해야 함

OAuth 2.0 Device Authorization Grant

기능: 브라우저나 복잡한 입력 인터페이스가 없는 장치를 위한 인증 방식이다.
작동 방식:
1. 장치에 사용자 코드와 확인 URI를 표시
2. 사용자가 다른 기기에서 해당 URI에 접속하여 표시된 코드를 입력하고 인증
3. 장치는 백그라운드에서 주기적으로 인증 상태를 확인하여 토큰 획득
활성화 시기:

  • 스마트 TV, IoT 기기, CLI 애플리케이션
  • 키보드 입력이 제한적이거나 브라우저가 없는 장치에서 인증이 필요한 경우

OIDC CIBA Grant

기능: Client Initiated Backchannel Authentication Flow로, 사용자 인증과 토큰 발급 과정이 분리되어 있는 인증 방식이다.
작동 방식:
1. 클라이언트가 사용자 식별자로 인증 요청을 Keycloak에 전송
2. Keycloak은 별도의 인증 장치(스마트폰 등)를 통해 사용자에게 인증 요청
3. 사용자가 인증 장치에서 인증을 완료하면 클라이언트는 토큰을 발급받음
활성화 시기:

  • 금융 서비스와 같은 높은 보안이 요구되는 애플리케이션
  • 온라인 결제 시스템에서 스마트폰을 인증 장치로 활용하는 경우
  • 사용자의 물리적 존재와 별도로 인증을 처리해야 하는 경우

2. 정리

인증 흐름활성화 여부사용 이유 및 설명
Standard flow (Authorization Code + PKCE)ON모바일/웹 앱(Flutter)에서 안전하게 인증 처리. PKCE 적용시 인증 코드 탈취 위험 감소
Direct access grants필요시앱에서 ID/비밀번호 직접 전송 필요시(예: 자체 백엔드 통신). 보안상 일반적 비권장
Implicit flowOFF보안 취약점으로 인해 폐기됨. Authorization Code + PKCE로 대체
Service accounts roles필요시서버-서버(Quarkus API ↔ Keycloak) 통신 등 사용자 개입 없는 시스템 간 인증 필요시 활성화
OAuth 2.0 Device Authorization GrantOFFIoT/TV/CLI 등 특수 장치가 아닌 일반 앱 환경에서는 불필요
OIDC CIBA GrantOFF금융 등 별도 인증 장치가 필요한 특수케이스 제외하고 일반 앱 환경에서는 사용하지 않음
profile
Server Developer

0개의 댓글