password 3

auth-sevice 배포 및 Keycloak과 연동

1. 이미지 빌드 및 푸시MSA 연동 과정에서 사용했던 auth-service 코드를 그대로 사용이미지를 생성해서 푸시하는 과정이므로 로컬에서 작업해도 무관Buildpacks 방식bootBuildImage가 제공하는 Cloud Native Buildpacks를 활용하여 이미지를 직접 생성JDK/JRE 버전 관리, 이미지 레이어화, 보안 패치 자동 반영Dockerfile처럼 세세한 커스터마이징 불가# Buildpacks 이미지 생성./gradlew bootBuildImage --imageName /auth-service:1.0.0# Docker Hub 푸시docker push /auth-service:1.0.0Dockerfile 방식직접 작성한 Dockerfile을 기반으로 이미지를 빌드이미지 레이어/구성..

Keycloak MSA 연동 구성 및 흐름

들어가며지금까지는 Keycloak의 기본 설정과 토큰 발급 과정을 개별적으로 살펴봤다.하지만 실제 서비스 환경에서는 Keycloak이 하나의 독립된 인증 서버로 동작하며,각각의 MSA 서비스(Spring Boot 애플리케이션) 와 통신하면서 사용자 인증과 권한을 관리한다. 이번 글에서는 Keycloak을 실제 MSA 구조 안에 연결해보며,사용자 로그인 흐름과 관리자 작업 흐름이 어떻게 다르게 동작하는지 살펴본다.사용자는 password 방식을 통해 로그인 후 Access Token을 발급받아 서비스 API를 호출하고,관리자는 client_credentials 방식을 통해 Admin Token을 발급받아Keycloak의 Admin API를 통해 사용자 CRUD 등의 관리 작업을 수행한다. DevOps 관점..

Keycloak 토큰 발급 방식

Keycloak은 OAuth 2.0/OIDC 표준을 바탕으로 여러 가지 토큰 발급 방식을 지원한다.겉으로 보기엔 “토큰 받기”가 전부 같아 보이지만, 실제로는 사용자 개입 여부, 보안 수준, 대상 워크로드가 모두 다르다.이번 글에서는 client_credentials, password, authorization_code를 중심으로 언제 어떤 방식을 써야 하는지를 정리하고, authorization_code 방식에서는 실습 가능한 cURL + 간단한 Spring Boot/프론트 흐름까지 연결해본다. 1. client_credentials 방식클라이언트 자체가 인증 주체가 되는 방식일반 사용자 로그인 없이 서비스 간 통신(Backend to Backend)에서 주로 사용세션 생성되지 않음발급된 토큰은..