Update Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md

Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md

@@ -456,6 +456,16 @@ Redis 대기 상태 예시:
 }
 ```
 
+여기서 `sessionJwt`는 Backend가 임의로 새로 만든 토큰으로 이해하면 안 된다. 링크/코드 기반 흐름에서는 Backend가 Kratos에 코드 검증 또는 세션 발급을 요청하고, Kratos가 반환한 `session_token`을 Backend가 `sessionJwt`라는 응답 필드명으로 UserFront에 전달한다.
+
+정리하면 다음과 같다.
+
+```text
+토큰 발급 주체: Kratos
+토큰 전달 주체: Baron Backend
+UserFront 응답 필드명: sessionJwt
+```
+
 ### 5.4 흐름도
 
 ```mermaid
@@ -467,7 +477,10 @@ sequenceDiagram
     participant GW as Baron Gateway Nginx
     participant BE as Baron Backend
     participant Redis as Redis
+    participant KA as Ory Kratos/Admin
     participant KR as Ory Kratos/Courier
+    participant HY as Ory Hydra
+    participant RP as RP/업무시스템
     participant Channel as Email/SMS
     participant Approver as 링크 승인 기기
 
@@ -475,7 +488,9 @@ sequenceDiagram
     UF->>L7: POST /api/v1/auth/enchanted-link/init
     L7->>GW: API 요청 전달
     GW->>BE: init 요청
-    BE->>BE: 사용자 존재 여부 확인, 전화번호 정규화
+    BE->>BE: 입력값 정리 및 전화번호 정규화
+    BE->>KA: IdpProvider.UserExists(loginId)로 identity 조회
+    KA-->>BE: 사용자 존재 여부 반환
     BE->>KR: 링크/코드 로그인 시작
     BE->>Redis: pendingRef 상태 저장(status=pending)
     KR-->>Channel: 로그인 링크 또는 코드 발송
@@ -491,9 +506,26 @@ sequenceDiagram
     Approver->>BE: POST /api/v1/auth/magic-link/verify 또는 /login/code/verify
     BE->>Redis: pendingRef 승인 처리(status=approved/success)
     UF->>BE: poll 재시도
-    BE-->>UF: sessionJwt
+    BE->>KR: Kratos 코드 검증/세션 발급 요청
+    KR-->>BE: Kratos session_token 반환
+    BE->>Redis: session_token을 pendingRef 성공 상태에 저장
+    alt RP OIDC 로그인 요청(login_challenge 있음)
+        BE->>HY: AcceptLoginRequest(login_challenge, subject)
+        HY-->>BE: redirectTo 반환
+        BE-->>UF: sessionJwt + redirectTo
+        UF->>RP: redirectTo 따라 RP callback 이동(code 포함)
+        RP->>HY: /oauth2/token에서 authorization code 교환
+        HY-->>RP: access_token, id_token, refresh_token 발급
+    else UserFront 일반 로그인(login_challenge 없음)
+        BE-->>UF: sessionJwt 필드로 Kratos session_token 전달
+    end
 ```
 
+위 그림의 마지막 단계는 두 가지로 나뉜다.
+
+- RP에서 시작된 OIDC 로그인이라면 `login_challenge`가 있으므로 Backend가 Hydra에 `AcceptLoginRequest`를 호출하고, RP는 최종적으로 Hydra에서 `access_token`, `id_token`, `refresh_token`을 받는다.
+- Baron UserFront 자체 로그인이라면 `login_challenge`가 없으므로 Hydra 후속 단계 없이 Kratos `session_token`을 `sessionJwt`로 받아 로그인 완료된다.
+
 ### 5.5 보안상 설명 포인트
 
 로그인 링크는 비밀번호를 입력하지 않아 편리하지만, 링크를 받은 사람이 곧 승인자가 된다. 따라서 운영 설명 시 다음 통제가 필요하다.