From db54d3921eb62441d854fc2feb7ab51c5da6576b 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 16:08:16 +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 --- Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md b/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md index b88249f..a3238dc 100644 --- a/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md +++ b/Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md @@ -384,6 +384,20 @@ sequenceDiagram 로그인 링크 방식의 핵심은 `pendingRef`이다. `pendingRef`는 "로그인을 기다리는 요청"을 식별하는 임시 키다. 현재 브라우저는 이 키로 계속 상태를 확인하고, 링크를 클릭한 쪽이 해당 키를 승인하면 현재 브라우저가 세션을 받는다. +사용자 존재 여부 확인은 Backend 핸들러에서 시작하지만, Backend가 자체 DB만 보고 단독 판단하는 구조로 이해하면 안 된다. Backend는 `IdpProvider.UserExists(loginId)`를 호출하고, 현재 Ory provider 기준으로는 Kratos Admin API를 통해 해당 loginId의 identity가 있는지 확인한다. + +즉 그림의 "사용자 존재 여부 확인"은 다음 의미다. + +```text +Baron Backend + -> IdpProvider.UserExists(loginId) + -> Ory/Kratos provider + -> Kratos Admin API 또는 IDP 조회 + -> identity 존재 여부 반환 +``` + +Backend가 이 확인을 먼저 하는 이유는 존재하지 않는 사용자에게 로그인 링크나 SMS를 보내지 않기 위해서다. 또한 휴대폰 번호 입력 시 `010-1234-5678` 같은 값을 `+821012345678` 형태로 정규화한 뒤 조회한다. + ### 5.3 데이터 예시 초기 요청: