Update 바론(Baron) SSO 통합 로그인 소개.md

2026-06-25 09:42:43 +09:00
parent 3dbf558dcf
commit 3c5f4ff594
1 changed files with 283 additions and 46 deletions
--- a/소개.md
+++ b/소개.md
@@ -1,73 +1,310 @@
-# 바론 SSO와 Ory 스택 — 팀원 대상 설명
+# 바론(Baron) SSO 통합 로그인 소개
 ---
-## 목적(한 문장)
+# 1. 제목
-팀원이 빠르게 이해하고 통합 작업을 시작할 수 있도록 Ory 컴포넌트와 바론 SSO 연동 방식을 실무 관점에서 설명합니다.
+- 바론 SSO 통합 로그인 소개
 - 개발자와 비개발자가 함께 이해하는 통합로그인 흐름
 발표자 노트:
 - 오늘 발표는 특정 기술을 깊게 파는 자리가 아니라, "우리 회사 로그인 입구가 어떻게 표준화되는가"를 같이 맞추는 자리라고 안내
 - 전체 목표: SSO 개념, Baron SSO 구성, 사용자가 실제로 지나가는 흐름, 각 부서 통합 절차 이해
 ---
-## 핵심 개념 (짧고 명확하게)
+# 2. Agenda
- Kratos: 사용자 계정·인증(로그인, 비밀번호, 세션)을 담당합니다. "누가 누구인지"를 관리합니다.
+- 왜 SSO가 필요한가
- Hydra: OAuth2/OIDC 토큰을 발급합니다. 서비스(클라이언트)가 인증을 위해 의존하는 엔진입니다.
+- Baron SSO가 하는 일과 하지 않는 일
- Oathkeeper: 서비스 앞단에서 토큰을 검사하고 요청을 허용/차단하는 프록시입니다.
+- Ory Stack과 내부 표준 기술 개요
- Keto(옵션): 세부 권한(ACL/정책) 판정을 외부에서 처리합니다.
+- 사용자가 로그인할 때 실제로 지나가는 길
 - RP/서비스 통합 방식
 - 보안/운영 고려사항
 - 데모 계획 및 다음 단계
 발표자 노트:
 - 비개발자에게는 "서비스 출입 체계", 개발자에게는 "OIDC 기반 표준 연동 방식"으로 설명
 - 기술 용어는 나오지만, 각 용어는 쉬운 역할 설명과 함께 다룰 예정이라고 안내
 ---
-## 한눈에 보는 흐름 (개발자가 알아야 할 핵심 흐름)
+# 3. 왜 SSO인가? (Pain Points)
-1. 사용자가 `userfront` 같은 서비스에 접근합니다.
+- 서비스마다 계정과 비밀번호를 따로 관리하면 사용자도 운영자도 힘들어짐
-2. 서비스는 사용자에게 Hydra의 인증 페이지로 리디렉션합니다 (OIDC Authorization).
+- 퇴사/부서 이동/권한 변경 시 누락이 생기기 쉬움
-3. 실제 로그인(아이디/비밀번호, MFA)은 Kratos에서 수행되고 세션이 만들어집니다.
+- 로그인 정책, MFA, 비밀번호 정책을 서비스마다 다르게 운영하기 어려움
-4. Kratos 인증 성공 후 코드가 Hydra로 돌아가고, Hydra는 토큰을 발급합니다.
+- 감사 로그가 흩어지면 사고 추적이 늦어짐
-5. 발급된 토큰으로 서비스가 사용자 세션을 구성하고 리소스에 접근합니다.
+- 신규 사내 시스템이 생길 때마다 인증을 새로 만드는 비용이 큼
-6. Oathkeeper가 앞단에 있으면 토큰 검증과 권한 시행은 중앙화됩니다.
+
 발표자 노트:
 - 핵심 메시지: SSO는 "한 번 로그인하면 편하다"만이 아니라, 계정 생명주기와 보안 운영을 중앙에서 관리하기 위한 기반
 ---
-## 팀별 체크리스트 (쉽게 실행 가능한 항목)
+# 4. Baron SSO란?
- 개발팀:
+- 회사 내부 서비스의 통합 인증/인가 계층
-	- Hydra에 `client_id`/`redirect_uri` 등록
+- 사용자가 누구인지 확인하고, 어떤 서비스에 접근하려는지 표준 방식으로 전달
-	- OIDC 라이브러리로 로그인 리디렉션/콜백 구현
+- OIDC/OAuth2 기반으로 RP(연동 서비스)에 로그인 결과를 제공
-	- 토큰(액세스/ID) 검증 구현 또는 Oathkeeper 사용
+- 중앙에서 사용자, 세션, 동의, 감사 로그를 관리
- 보안팀:
+
-	- 토큰 만료·리프레시 정책 검토
+발표자 노트:
-	- TLS, 시크릿 관리 정책 점검
+- Baron SSO는 각 업무 시스템을 대체하는 서비스가 아니라, 업무 시스템 앞에서 "공통 출입증" 역할을 하는 계층
- 운영팀:
+- 각 RP의 업무 권한은 RP 또는 중앙 권한 정책과 함께 판단됨
 	- Ory 컴포넌트 모니터링(헬스체크, 로그 수집)
 	- 스테이징/프로덕션 분리 및 백업 절차 수립
 ---
-## 빠른 통합 단계 (실무 명령형)
+# 5. Baron SSO가 하는 일 / 하지 않는 일
-1. 로컬에서 스택 기동: `docker compose -f docker/compose.ory.yaml up` (환경변수 확인)
+
-2. Kratos 사용자 스키마 확인 및 필요시 매핑 수정
+하는 일:
-3. Hydra에 서비스 클라이언트 등록(redirect URI, grant types, scopes)
+- 통합 로그인 계정 생성 및 인증
-4. 프론트엔드에서 로그인 흐름 테스트(리디렉션 → 로그인 → 콜백)
+- SSO 세션 관리
-5. Oathkeeper 정책을 적용해 서비스 접근 제어 검증
+- RP에 사용자 식별 정보와 토큰 전달
-6. 통합 테스트 케이스를 작성해 반복 검증
+- 로그인/동의/연동/해지 이력 기록
 - 중앙 권한 정책과 연계할 수 있는 기반 제공
 하지 않는 일:
 - 회원가입만으로 모든 사내 시스템 권한을 자동 부여하지 않음
 - 각 RP의 업무 데이터 권한을 무조건 대신 결정하지 않음
 - RP 내부의 모든 화면과 기능을 자동으로 만들어주지 않음
 발표자 노트:
 - 중요한 오해 방지: "Baron SSO 가입 = 모든 시스템 무제한 이용"이 아님
 - 가입은 통합로그인 계정 생성이고, 서비스 이용 가능 여부는 RP 연동 설정, 동의, 소속/권한 정책으로 결정됨
 ---
-## 데모/점검 체크리스트 (발표·검증용)
+# 6. 용어를 먼저 정리하기
- 브라우저에서 서비스 접속 → SSO 로그인 흐름 정상 동작 확인
+- 사용자 브라우저: 사용자가 실제로 보는 화면. 로그인 리디렉션과 쿠키/세션이 여기서 시작됨
- 토큰 클레임(`iss`, `aud`, `exp`)과 사용자 정보 정상 매핑 확인
+- RP / Client: Baron SSO를 이용해 로그인하려는 업무 시스템. 예: `userfront`, `adminfront`, `orgfront`, 외부 연동앱
- Oathkeeper 사용 시, 인증 실패/권한 없음 케이스 확인
+- OIDC/OAuth2: "내가 누구인지"를 안전하게 전달하기 위한 표준 로그인 프로토콜
- 로그(인증/토큰/권한 변경)가 중앙에 수집되는지 확인
+- Token: 로그인 결과를 서비스가 검증할 수 있게 만든 전자 출입증
 - Scope / Consent: RP가 어떤 정보나 권한을 요청하는지 사용자에게 확인하는 절차
 발표자 노트:
 - RP는 "Relying Party", 즉 SSO를 믿고 로그인 결과를 받아 쓰는 서비스라고 설명
 - Token은 비밀번호가 아니라 검증 가능한 증명서에 가깝다고 설명
 ---
-## 레포지토리 참조(빠른 위치)
+# 7. Ory Stack 개요
- Ory 관련 Compose 예시: [docker/compose.ory.yaml](docker/compose.ory.yaml)
+- Kratos: 계정, 회원가입, 로그인, 세션을 담당
- 루트 배포 템플릿: [compose.ory.yaml](compose.ory.yaml)
+- Hydra: OIDC/OAuth2 토큰 발급과 RP 연동을 담당
- 주요 서비스: `userfront`, `adminfront` (각 서비스는 Hydra 클라이언트로 등록 필요)
+- Oathkeeper: 서비스 앞단에서 요청을 검사하고 통과/차단을 결정
 - Keto: "누가 무엇을 할 수 있는가"를 판단하는 권한 엔진
 발표자 노트:
 - 쉬운 비유:
  - Kratos = 신분증 발급/본인 확인 창구
  - Hydra = 제휴 서비스에 제출할 공식 확인서 발급 창구
  - Oathkeeper = 출입구 보안 담당
  - Keto = 권한 규칙표와 판정 담당
 ---
-## 다음 행동(권장)
+# 8. 내부 표준 기술
-1. 각 팀은 위의 체크리스트 항목 중 담당 항목 선택 후 담당자·일정 등록
+- OIDC/OAuth2: RP 연동의 기본 표준
-2. 내가 도와줄 수 있는 작업: 클라이언트 등록 샘플, `docker compose` 실행 가이드, 프레임워크별 코드 스니펫 제공
+- HTTPS/TLS: 브라우저와 서버 간 통신 보호
 - Reverse Proxy / Gateway: 외부 요청을 내부 서비스로 안전하게 전달
 - Nginx: Baron SSO 내부 게이트웨이 역할. `/api`, `/auth`, `/oidc`, 화면 요청을 알맞은 서비스로 분기
 - Oathkeeper Rules: 어떤 URL을 어떤 인증/권한 규칙으로 보호할지 정의
 - 중앙 로그/감사: 로그인, 동의, 권한 변경, 접근 실패를 추적
 발표자 노트:
 - "표준 기술"의 목적은 새 시스템마다 다른 로그인 방식을 만들지 않기 위함
 - 개발자는 OIDC 연동만 맞추면 되고, 운영/보안은 중앙 정책으로 일관성을 유지할 수 있음
 ---
-원하시면 이 문서에 실제 환경변수 목록, 포트/엔드포인트 예시, 또는 프레임워크별 코드 스니펫을 추가하겠습니다.
+# 9. 전체 구조 한눈에 보기
 ```mermaid
 flowchart LR
    U[사용자 브라우저]
    L7[L7 / 외부 진입점]
    NG[Nginx Gateway]
    OK[Oathkeeper]
    UF[UserFront<br/>로그인 화면]
    BE[Baron Backend]
    KR[Ory Kratos<br/>계정/세션]
    HY[Ory Hydra<br/>OIDC 토큰]
    KE[Ory Keto<br/>권한 판정]
    RP[RP / 업무 시스템]
    U --> L7 --> NG
    NG --> UF
    NG --> BE
    NG --> OK
    OK --> KR
    OK --> HY
    BE --> KR
    BE --> HY
    BE --> KE
    U --> RP
    RP --> HY
 ```
 발표자 노트:
 - L7은 회사 외부/내부 네트워크에서 들어오는 요청의 첫 관문
 - Nginx는 "이 요청은 화면으로, 이 요청은 API로, 이 요청은 Ory로" 보내는 교통정리 담당
 - Oathkeeper는 `/auth`, `/oidc` 같은 Ory 공개 경로 앞에서 정책을 적용
 ---
 # 10. 사용자 브라우저가 하는 일
 - 사용자가 RP에 접속하고 로그인 버튼을 누름
 - RP에서 Baron SSO 로그인 화면으로 이동함
 - 로그인/회원가입/동의 화면을 보여줌
 - 로그인 완료 후 원래 RP로 돌아감
 - 쿠키, 세션, 리디렉션이 브라우저를 통해 오감
 발표자 노트:
 - 사용자는 "여러 번 이동하는 것처럼" 보지만, 실제로는 표준 로그인 절차를 따라 RP와 SSO가 정보를 주고받는 과정
 - 사용자가 비밀번호를 RP에 직접 주는 구조가 아니라 SSO에서 인증하고 결과만 RP가 받는 구조임
 ---
 # 11. L7, Nginx, Oathkeeper를 쉽게 이해하기
 - L7: 도메인과 경로 기준으로 외부 요청을 받아주는 앞문
 - Nginx Gateway: Baron 내부에서 요청을 목적지별로 나누는 안내 데스크
 - Oathkeeper: 보호된 경로 앞에서 세션/토큰/규칙을 확인하는 보안 게이트
 - Backend: 실제 Baron 정책, 사용자 조회, 감사 기록, Ory Admin 연동을 수행하는 업무 처리 담당
 발표자 노트:
 - 요청 흐름 예시:
  - `/` 화면 요청 → Nginx → UserFront
  - `/api` API 요청 → Nginx → Backend
  - `/auth` Kratos 공개 API → Nginx → Oathkeeper → Kratos
  - `/oidc` Hydra 공개 API → Nginx → Oathkeeper → Hydra
 ---
 # 12. 로그인 흐름(요약)
 1. 사용자가 RP에 접속
 2. RP가 Baron SSO로 로그인 요청
 3. Hydra가 로그인 챌린지를 만들고 UserFront로 이동시킴
 4. UserFront에서 Kratos 기반 로그인 또는 회원가입 진행
 5. 인증 성공 후 Backend가 Hydra 로그인/동의 요청을 승인
 6. Hydra가 RP에 authorization code 전달
 7. RP가 code를 token으로 교환하고 사용자 세션 생성
 발표자 노트:
 - Hydra는 "RP와 표준 프로토콜로 대화하는 창구"
 - Kratos는 "실제 사용자가 누구인지 확인하는 계정 시스템"
 - Backend는 둘 사이의 흐름을 Baron 정책에 맞게 조정하는 역할
 ---
 # 13. 회원가입 흐름에서 중요한 점
 - 특정 RP에서 회원가입 버튼을 눌러도 생성되는 계정은 Baron SSO 통합로그인 계정
 - 가입 완료 후에는 처음 접근했던 RP로 돌아감
 - RP는 이 사용자가 처음 들어온 경우 자체 사용자 레코드를 만들거나 매핑할 수 있음
 - RP 사용 가능 여부는 RP 등록, 동의, scope, 소속/권한 정책에 따라 결정됨
 발표자 노트:
 - "특정 RP 전용 회원가입"이 아니라 "Baron SSO 계정을 만들고 해당 RP에 최초 접근하는 흐름"
 - 이 슬라이드는 비개발자 질문이 많이 나올 수 있으므로 천천히 설명
 ---
 # 14. 권한 흐름: 로그인과 권한은 다르다
 - 로그인: 사용자가 누구인지 확인
 - 동의: RP가 어떤 정보를 요청하는지 확인
 - 권한: 그 사용자가 해당 기능/데이터를 사용할 수 있는지 판단
 - Baron SSO 계정의 기본 권한은 일반 사용자(`user`)
 - 관리자, RP 운영자, 테넌트 관리자 권한은 별도 부여와 검증이 필요
 발표자 노트:
 - 예시: 회사 출입증이 있어도 모든 회의실, 서버실, 금고에 들어갈 수 있는 것은 아님
 - Baron SSO는 공통 신원 확인을 제공하고, 민감 기능은 권한 정책으로 한 번 더 제어
 ---
 # 15. RP 통합 방법(개발팀 가이드)
 - Hydra에 RP Client 등록
  - `client_id`, redirect URI, logout URI, 허용 scope 설정
 - RP에서 OIDC 라이브러리 적용
  - 로그인 리디렉션
  - callback 처리
  - token 검증
 - 사용자 매핑 방식 결정
  - Baron subject 또는 external key 기준
  - 이메일은 변경될 수 있으므로 단독 primary key로 쓰지 않는 것을 권장
 - 권한 매핑 결정
  - scope, tenant claim, Keto check, RP 내부 역할 중 어떤 기준을 쓸지 정함
 발표자 노트:
 - 개발팀에는 "직접 인증을 새로 만들지 말고 표준 OIDC client로 붙는다"가 핵심
 - RP별 권한 모델은 업무 특성에 따라 다르므로 사전 합의 필요
 ---
 # 16. 비개발 부서가 알아야 할 통합 체크포인트
 - 이 서비스는 어떤 사용자 그룹이 쓰는가
 - 외부 협력사 또는 개인 계정도 허용하는가
 - 퇴사/이동/겸직 시 권한은 어떻게 회수되는가
 - RP에서 필요한 사용자 정보는 무엇인가
 - 관리자 권한은 누가 승인하고 누가 회수하는가
 - 감사 로그로 어떤 이벤트를 남겨야 하는가
 발표자 노트:
 - SSO 통합은 개발 작업만이 아니라 운영 정책 합의가 필요한 일
 - 특히 권한 부여/회수 책임자가 정해져야 운영 사고가 줄어듦
 ---
 # 17. 보안 및 운영 고려사항
 - HTTPS/TLS 강제
 - redirect URI 사전 등록과 검증
 - 토큰 수명, refresh, logout 정책
 - Admin API와 내부 포트는 외부에 직접 노출하지 않음
 - 시크릿과 client secret은 저장소에 평문 커밋하지 않음
 - 로그인 실패, 동의, 권한 변경, 관리자 작업은 감사 로그로 추적
 - 스테이징과 운영 환경 분리
 발표자 노트:
 - 인증 시스템은 "잘 되는 것"만큼 "잘못된 요청을 막는 것"이 중요
 - 운영에서 가장 위험한 것은 임시 예외가 문서화되지 않고 오래 남는 경우
 ---
 # 18. 데모 계획
 - 시나리오 1: RP 접속 → Baron SSO 로그인 → RP 복귀
 - 시나리오 2: 특정 RP에서 회원가입 → Baron SSO 계정 생성 → 원래 RP 복귀
 - 시나리오 3: 동의 화면 또는 이미 동의된 RP 자동 진입 확인
 - 시나리오 4: 권한 없는 화면 접근 시 차단 확인
 - 시나리오 5: 감사 로그 또는 연동 앱 목록 확인
 발표자 노트:
 - 비개발자에게는 화면 흐름 위주로 보여주고, 개발자 질문이 나오면 네트워크/토큰/로그를 추가로 보여주는 방식 추천
 ---
 # 19. 도입 시 역할 분담
 - 서비스 담당팀: RP 등록 정보, callback URL, 필요한 claim/scope 정의
 - Baron SSO 담당팀: Client 등록, 정책 검토, 연동 테스트 지원
 - 보안/운영팀: 권한 부여 기준, 로그 보존, 장애/비상 대응 기준 검토
 - 현업 담당자: 사용자 범위, 승인권자, 업무 권한 정책 확인
 발표자 노트:
 - 통합은 "개발 완료"보다 "운영 책임 경계 확정"이 더 중요할 수 있음
 - 담당자와 승인 절차가 없으면 SSO가 편해져도 권한 운영은 다시 흐려짐
 ---
 # 20. Q&A 및 다음 단계
 - 각 RP별 통합 대상과 우선순위 정리
 - 서비스별 callback URL, logout URL, 필요한 사용자 정보 수집
 - 스테이징에서 OIDC 연동 테스트
 - 권한/동의/감사 로그 정책 확정
 - 운영 전환 체크리스트 작성
 발표자 노트:
 - 마지막에는 "SSO 계정 생성", "RP 접근", "업무 권한"이 서로 다른 단계라는 점을 다시 강조
 - 질문이 개발 상세로 깊어지면 별도 기술 세션 또는 통합 가이드로 이어가기
 ---
 (부록) 참고 자료
 - [docs/ory-stack-guide.md](../docs/ory-stack-guide.md)
 - [docs/ory-usage.md](../docs/ory-usage.md)
 - [docs/rp-iam-integration-guide.md](../docs/rp-iam-integration-guide.md)
 - [docs/rbac-rebac-policy.md](../docs/rbac-rebac-policy.md)
 - [gateway/nginx.conf](../gateway/nginx.conf)