From f3e77065adf5aac45c92af398a37b54cda95fd6d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EB=AC=B8=ED=98=95=EC=84=9D?= Date: Mon, 22 Jun 2026 15:52:20 +0900 Subject: [PATCH] =?UTF-8?q?Update=20Baron=20SSO=20=EB=A1=9C=EA=B7=B8?= =?UTF-8?q?=EC=9D=B8=20=ED=99=94=EB=A9=B4=203=EA=B0=80=EC=A7=80=20?= =?UTF-8?q?=EB=B0=A9=EC=8B=9D=20=EC=A0=88=EC=B0=A8=20=EB=B0=8F=20=ED=9D=90?= =?UTF-8?q?=EB=A6=84.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...SSO 로그인 화면 3가지 방식 절차 및 흐름.md | 91 ++++++++++++++++++- 1 file changed, 90 insertions(+), 1 deletion(-) diff --git a/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md b/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md index de76092..b88249f 100644 --- a/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md +++ b/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md @@ -42,7 +42,96 @@ Baron SSO 로그인 페이지에는 사용자가 선택할 수 있는 로그인 따라서 L7, Nginx, Oathkeeper는 사용자를 인증하는 주체라기보다 "요청을 올바른 내부 서비스로 안전하게 전달하는 앞단 계층"에 가깝다. 실제 로그인 요청 접수와 OIDC 판단은 Hydra가 하고, 비밀번호 검증과 세션 발급은 Backend와 Kratos가 처리한다. -### 3.1 Hydra가 먼저 나오는 이유 +중요한 점은 모든 요청이 Oathkeeper를 거치는 것은 아니라는 것이다. Oathkeeper는 주로 Ory Public endpoint 앞단에 붙어 있다. UserFront 화면 요청과 Baron Backend API 요청은 Nginx에서 각각 UserFront와 Backend로 직접 라우팅된다. + +요청 종류별 경로는 다음과 같이 구분된다. + +| 요청 종류 | 예시 | 실제 경로 | Oathkeeper 경유 여부 | +| --- | --- | --- | --- | +| 로그인 화면 요청 | `/`, `/ko/login?login_challenge=...` | 브라우저 -> L7 -> Nginx -> UserFront | 경유하지 않음 | +| Baron Backend API 요청 | `/api/v1/auth/password/login`, `/api/v1/auth/qr/init` | UserFront -> L7 -> Nginx -> Backend | 경유하지 않음 | +| Ory Public 요청 | `/oidc/oauth2/auth`, `/auth/*` | 브라우저/RP -> L7 -> Nginx -> Oathkeeper -> Hydra/Kratos Public | 경유함 | +| Backend 내부 백채널 | `GetLoginRequest`, `AcceptLoginRequest`, Kratos 세션 발급 | Backend -> Hydra Admin/Kratos API/Redis | 경유하지 않음 | + +즉 로그인 화면이 표시될 때의 UserFront 요청은 Oathkeeper를 거치지 않는다. 반면 RP가 처음 보낸 `/oidc/oauth2/auth` 요청은 Ory Public endpoint이므로 Nginx에서 Oathkeeper로 보내고, Oathkeeper가 Hydra로 전달한다. + +헷갈리기 쉬운 두 경로를 분리하면 다음과 같다. + +```text +로그인 화면 요청: +사용자 브라우저 -> L7 -> Baron Gateway Nginx -> UserFront + +OIDC 인증 요청: +사용자 브라우저/RP -> L7 -> Baron Gateway Nginx -> Oathkeeper -> Hydra + +로그인 버튼/API 요청: +UserFront -> L7 -> Baron Gateway Nginx -> Baron Backend + +Backend 내부 완료 처리: +Baron Backend -> Hydra Admin API +``` + +다만 위 표는 "요청 종류별 경로"를 나눈 것이고, 사용자가 RP에 접속한 뒤 Baron SSO 로그인 화면에 도달하기까지의 실제 시간 순서는 아래처럼 하나의 흐름으로 이어진다. + +### 3.1 RP 접속부터 Baron SSO 로그인 화면 도달까지 + +사용자가 RP 업무시스템에 접속했는데 RP 세션이 없을 때, Baron SSO 로그인 화면이 뜨기까지의 순서는 다음과 같다. + +```text +1. 사용자 브라우저 -> RP 업무시스템 + 사용자가 RP의 보호 페이지에 접속한다. + +2. RP 업무시스템 + RP가 자기 시스템의 로그인 세션을 확인한다. + 세션이 없으면 Baron SSO로 보내야 한다고 판단한다. + +3. RP 업무시스템 -> 사용자 브라우저 + RP가 브라우저에게 Baron SSO OIDC 인증 URL로 이동하라고 응답한다. + 예: /oidc/oauth2/auth?client_id=...&redirect_uri=...&scope=...&state=... + +4. 사용자 브라우저 -> L7 -> Baron Gateway Nginx + 브라우저가 Baron SSO의 /oidc/oauth2/auth 주소로 이동한다. + +5. Baron Gateway Nginx -> Oathkeeper -> Hydra + Nginx는 /oidc/* 경로이므로 Oathkeeper로 보낸다. + Oathkeeper는 이를 Hydra Public endpoint로 전달한다. + +6. Hydra + client_id, redirect_uri, scope, state, nonce, code_challenge 등을 확인한다. + 즉, RP의 OIDC 로그인 요청이 정상인지 접수/검증한다. + +7. Hydra + 사용자의 Baron SSO 로그인 세션이 없으면 login_challenge를 만든다. + +8. Hydra -> 사용자 브라우저 + Hydra가 브라우저에게 UserFront 로그인 화면으로 이동하라고 리다이렉트한다. + 예: /login?login_challenge=... + +9. 사용자 브라우저 -> L7 -> Baron Gateway Nginx -> UserFront + 브라우저가 실제 로그인 화면 URL을 다시 요청한다. + 이 요청은 / 또는 /login 화면 요청이므로 Oathkeeper를 거치지 않고 UserFront로 간다. + +10. UserFront -> 사용자 브라우저 + 비밀번호 / 로그인 링크 / QR 코드 탭이 있는 Baron SSO 로그인 화면이 표시된다. +``` + +핵심은 "두 번의 브라우저 이동"이 있다는 점이다. + +첫 번째 이동은 RP가 Baron SSO의 OIDC endpoint로 보내는 이동이다. + +```text +사용자 브라우저 -> L7 -> Nginx -> Oathkeeper -> Hydra +``` + +두 번째 이동은 Hydra가 UserFront 로그인 화면으로 보내는 이동이다. + +```text +사용자 브라우저 -> L7 -> Nginx -> UserFront +``` + +따라서 "로그인 화면 요청은 Oathkeeper를 거치지 않는다"는 말은 두 번째 이동에 대한 설명이다. 반대로 "RP의 OIDC 인증 요청은 Oathkeeper를 거친다"는 말은 첫 번째 이동에 대한 설명이다. + +### 3.2 Hydra가 먼저 나오는 이유 처음 흐름을 보면 Hydra가 Kratos보다 먼저 등장하기 때문에 혼동될 수 있다. 직관적으로는 "사용자 인증은 Kratos가 담당하니 Kratos가 먼저 나와야 하는 것 아닌가?"라고 생각할 수 있다.