Update Baron SSO 로그인 화면 3가지 방식 절차 및 흐름.md
This commit is contained in:
@@ -69,6 +69,61 @@ flowchart LR
|
||||
|
||||
## 4. 비밀번호 로그인
|
||||
|
||||
### 4.0 로그인 화면이 뜨기 전 순서
|
||||
|
||||
RP 화면에서 사용자가 로그인을 시도하면, 바로 비밀번호 검증이나 토큰 검증부터 하는 것이 아니다. 먼저 OIDC 인증 요청을 Baron SSO의 Hydra endpoint로 보낸다.
|
||||
|
||||
이때 Hydra가 확인하는 것은 주로 다음과 같다.
|
||||
|
||||
- `client_id`: 어떤 RP 시스템이 요청했는지
|
||||
- `redirect_uri`: 로그인 후 돌아갈 주소가 등록된 주소인지
|
||||
- `scope`: RP가 요청한 권한 범위
|
||||
- `state`, `nonce`, `code_challenge`: OIDC/PKCE 흐름을 안전하게 이어가기 위한 값
|
||||
- 기존 Baron SSO 로그인 세션 존재 여부
|
||||
|
||||
즉, 처음 `/oidc/oauth2/auth`로 들어온 요청은 "토큰 확인"이라기보다 "OIDC 로그인 요청 접수 및 검증"에 가깝다. 사용자가 아직 Baron SSO에 로그인되어 있지 않으면 Hydra는 `login_challenge`를 만들고, 사용자를 Baron SSO 로그인 화면(UserFront)으로 보낸다.
|
||||
|
||||
흐름을 로그인 화면 표시 전까지만 보면 다음과 같다.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
actor User as 사용자
|
||||
participant RP as RP/업무시스템
|
||||
participant L7 as L7/Traefik
|
||||
participant GW as Baron Gateway Nginx
|
||||
participant OK as Oathkeeper
|
||||
participant HY as Ory Hydra
|
||||
participant UF as UserFront 로그인 화면
|
||||
|
||||
User->>RP: 업무시스템 접속
|
||||
User->>RP: 로그인 버튼 클릭
|
||||
RP-->>User: /oidc/oauth2/auth로 브라우저 리다이렉트
|
||||
User->>L7: GET /oidc/oauth2/auth?client_id=...&redirect_uri=...
|
||||
L7->>GW: 요청 전달
|
||||
GW->>OK: /oidc/* 경로 전달
|
||||
OK->>HY: strip_path 후 Hydra /oauth2/auth 전달
|
||||
HY->>HY: client_id, redirect_uri, scope, state, PKCE 검증
|
||||
alt 기존 Baron SSO 로그인 세션 없음
|
||||
HY-->>User: login_challenge 포함 UserFront 로그인 화면으로 리다이렉트
|
||||
User->>L7: UserFront 로그인 화면 요청
|
||||
L7->>GW: 화면 요청 전달
|
||||
GW->>UF: / 경로 UserFront로 전달
|
||||
UF-->>User: 비밀번호/로그인 링크/QR 코드 화면 표시
|
||||
else 기존 Baron SSO 로그인 세션 있음
|
||||
HY-->>User: 로그인 화면 생략 또는 consent/redirect 단계로 진행
|
||||
end
|
||||
```
|
||||
|
||||
정리하면 다음 순서다.
|
||||
|
||||
1. 사용자가 RP에 접속한다.
|
||||
2. RP가 `client_id` 등을 담아 Baron SSO의 `/oidc/oauth2/auth`로 브라우저를 보낸다.
|
||||
3. 요청은 L7, Baron Gateway Nginx, Oathkeeper를 거쳐 Hydra로 간다.
|
||||
4. Hydra는 RP 요청이 정상인지 확인하고, 기존 SSO 세션이 있는지 본다.
|
||||
5. 로그인 세션이 없으면 `login_challenge`를 발급하고 UserFront 로그인 화면으로 보낸다.
|
||||
6. 그 다음에야 사용자가 비밀번호/로그인 링크/QR 코드 중 하나를 선택한다.
|
||||
|
||||
### 4.1 사용자가 보는 절차
|
||||
|
||||
1. 사용자가 `비밀번호` 탭을 선택한다.
|
||||
@@ -115,6 +170,10 @@ flowchart LR
|
||||
|
||||
### 4.4 흐름도
|
||||
|
||||
아래 흐름도는 "로그인 화면 표시 전 OIDC 요청 접수"와 "비밀번호 입력 후 세션 발급"을 한 번에 이어서 보여준다.
|
||||
|
||||
주의할 점은 4번의 `/oidc/* -> Hydra` 단계가 비밀번호나 access token을 검사하는 단계가 아니라는 것이다. 이 단계는 RP의 OIDC 인증 요청을 Hydra가 접수하고, `client_id`와 `redirect_uri` 등을 확인한 뒤 `login_challenge`를 만들어 UserFront 로그인 화면으로 보내는 단계다.
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
autonumber
|
||||
@@ -122,16 +181,21 @@ sequenceDiagram
|
||||
participant RP as RP/업무시스템
|
||||
participant L7 as L7/Traefik
|
||||
participant GW as Baron Gateway Nginx
|
||||
participant OK as Oathkeeper
|
||||
participant UF as UserFront
|
||||
participant BE as Baron Backend
|
||||
participant KR as Ory Kratos
|
||||
participant HY as Ory Hydra
|
||||
|
||||
User->>RP: 업무시스템 접속
|
||||
RP->>L7: /oidc/oauth2/auth?client_id=...
|
||||
RP-->>User: /oidc/oauth2/auth?client_id=... 로 리다이렉트
|
||||
User->>L7: GET /oidc/oauth2/auth?client_id=...
|
||||
L7->>GW: OIDC 요청 전달
|
||||
GW->>HY: /oidc/* -> Hydra
|
||||
HY-->>UF: login_challenge 포함 로그인 화면 이동
|
||||
GW->>OK: /oidc/* 경로 전달
|
||||
OK->>HY: Hydra /oauth2/auth 전달
|
||||
HY->>HY: RP 요청 검증 및 login_challenge 생성
|
||||
HY-->>User: UserFront 로그인 화면으로 리다이렉트
|
||||
User->>UF: 로그인 화면 표시
|
||||
User->>UF: 이메일/휴대폰 + 비밀번호 입력
|
||||
UF->>L7: POST /api/v1/auth/password/login
|
||||
L7->>GW: API 요청 전달
|
||||
@@ -425,4 +489,3 @@ QR 코드는 "새 PC 화면에 임시 출입증을 띄우고, 이미 로그인
|
||||
4. 링크/QR 방식 모두 `요청자 기기`와 `승인자 기기`를 감사 로그에 분리 저장한다.
|
||||
5. `내가 요청한 로그인이 아님`을 누르면 해당 pending 요청을 즉시 차단하고, 이미 발급된 세션 또는 refresh grant가 있으면 단계적으로 revoke한다.
|
||||
6. 내부 사용자는 Naver Works 같은 조직 채널 알림과 연동할 수 있지만, 외부 사용자는 이메일/패스키/TOTP 등 별도 신뢰 채널을 마련해야 한다.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user