kevin/MyDoc

Fork 0

Files

문형석 3c5f4ff594 Update 바론(Baron) SSO 통합 로그인 소개.md

2026-06-25 09:42:43 +09:00

13 KiB

Raw Blame History

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

1. 제목

바론 SSO 통합 로그인 소개
개발자와 비개발자가 함께 이해하는 통합로그인 흐름

발표자 노트:

오늘 발표는 특정 기술을 깊게 파는 자리가 아니라, "우리 회사 로그인 입구가 어떻게 표준화되는가"를 같이 맞추는 자리라고 안내
전체 목표: SSO 개념, Baron SSO 구성, 사용자가 실제로 지나가는 흐름, 각 부서 통합 절차 이해

2. Agenda

왜 SSO가 필요한가
Baron SSO가 하는 일과 하지 않는 일
Ory Stack과 내부 표준 기술 개요
사용자가 로그인할 때 실제로 지나가는 길
RP/서비스 통합 방식
보안/운영 고려사항
데모 계획 및 다음 단계

발표자 노트:

비개발자에게는 "서비스 출입 체계", 개발자에게는 "OIDC 기반 표준 연동 방식"으로 설명
기술 용어는 나오지만, 각 용어는 쉬운 역할 설명과 함께 다룰 예정이라고 안내

3. 왜 SSO인가? (Pain Points)

서비스마다 계정과 비밀번호를 따로 관리하면 사용자도 운영자도 힘들어짐
퇴사/부서 이동/권한 변경 시 누락이 생기기 쉬움
로그인 정책, MFA, 비밀번호 정책을 서비스마다 다르게 운영하기 어려움
감사 로그가 흩어지면 사고 추적이 늦어짐
신규 사내 시스템이 생길 때마다 인증을 새로 만드는 비용이 큼

발표자 노트:

핵심 메시지: SSO는 "한 번 로그인하면 편하다"만이 아니라, 계정 생명주기와 보안 운영을 중앙에서 관리하기 위한 기반

4. Baron SSO란?

회사 내부 서비스의 통합 인증/인가 계층
사용자가 누구인지 확인하고, 어떤 서비스에 접근하려는지 표준 방식으로 전달
OIDC/OAuth2 기반으로 RP(연동 서비스)에 로그인 결과를 제공
중앙에서 사용자, 세션, 동의, 감사 로그를 관리

발표자 노트:

Baron SSO는 각 업무 시스템을 대체하는 서비스가 아니라, 업무 시스템 앞에서 "공통 출입증" 역할을 하는 계층
각 RP의 업무 권한은 RP 또는 중앙 권한 정책과 함께 판단됨

5. Baron SSO가 하는 일 / 하지 않는 일

하는 일:

통합 로그인 계정 생성 및 인증
SSO 세션 관리
RP에 사용자 식별 정보와 토큰 전달
로그인/동의/연동/해지 이력 기록
중앙 권한 정책과 연계할 수 있는 기반 제공

하지 않는 일:

회원가입만으로 모든 사내 시스템 권한을 자동 부여하지 않음
각 RP의 업무 데이터 권한을 무조건 대신 결정하지 않음
RP 내부의 모든 화면과 기능을 자동으로 만들어주지 않음

발표자 노트:

중요한 오해 방지: "Baron SSO 가입 = 모든 시스템 무제한 이용"이 아님
가입은 통합로그인 계정 생성이고, 서비스 이용 가능 여부는 RP 연동 설정, 동의, 소속/권한 정책으로 결정됨

6. 용어를 먼저 정리하기

사용자 브라우저: 사용자가 실제로 보는 화면. 로그인 리디렉션과 쿠키/세션이 여기서 시작됨
RP / Client: Baron SSO를 이용해 로그인하려는 업무 시스템. 예: userfront, adminfront, orgfront, 외부 연동앱
OIDC/OAuth2: "내가 누구인지"를 안전하게 전달하기 위한 표준 로그인 프로토콜
Token: 로그인 결과를 서비스가 검증할 수 있게 만든 전자 출입증
Scope / Consent: RP가 어떤 정보나 권한을 요청하는지 사용자에게 확인하는 절차

발표자 노트:

RP는 "Relying Party", 즉 SSO를 믿고 로그인 결과를 받아 쓰는 서비스라고 설명
Token은 비밀번호가 아니라 검증 가능한 증명서에 가깝다고 설명

7. Ory Stack 개요

Kratos: 계정, 회원가입, 로그인, 세션을 담당
Hydra: OIDC/OAuth2 토큰 발급과 RP 연동을 담당
Oathkeeper: 서비스 앞단에서 요청을 검사하고 통과/차단을 결정
Keto: "누가 무엇을 할 수 있는가"를 판단하는 권한 엔진

발표자 노트:

쉬운 비유:
- Kratos = 신분증 발급/본인 확인 창구
- Hydra = 제휴 서비스에 제출할 공식 확인서 발급 창구
- Oathkeeper = 출입구 보안 담당
- Keto = 권한 규칙표와 판정 담당

8. 내부 표준 기술

OIDC/OAuth2: RP 연동의 기본 표준
HTTPS/TLS: 브라우저와 서버 간 통신 보호
Reverse Proxy / Gateway: 외부 요청을 내부 서비스로 안전하게 전달
Nginx: Baron SSO 내부 게이트웨이 역할. /api, /auth, /oidc, 화면 요청을 알맞은 서비스로 분기
Oathkeeper Rules: 어떤 URL을 어떤 인증/권한 규칙으로 보호할지 정의
중앙 로그/감사: 로그인, 동의, 권한 변경, 접근 실패를 추적

발표자 노트:

"표준 기술"의 목적은 새 시스템마다 다른 로그인 방식을 만들지 않기 위함
개발자는 OIDC 연동만 맞추면 되고, 운영/보안은 중앙 정책으로 일관성을 유지할 수 있음

9. 전체 구조 한눈에 보기

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. 로그인 흐름(요약)

사용자가 RP에 접속
RP가 Baron SSO로 로그인 요청
Hydra가 로그인 챌린지를 만들고 UserFront로 이동시킴
UserFront에서 Kratos 기반 로그인 또는 회원가입 진행
인증 성공 후 Backend가 Hydra 로그인/동의 요청을 승인
Hydra가 RP에 authorization code 전달
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 접근", "업무 권한"이 서로 다른 단계라는 점을 다시 강조
질문이 개발 상세로 깊어지면 별도 기술 세션 또는 통합 가이드로 이어가기

(부록) 참고 자료

13 KiB Raw Blame History

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

1. 제목

2. Agenda

3. 왜 SSO인가? (Pain Points)

4. Baron SSO란?

5. Baron SSO가 하는 일 / 하지 않는 일

6. 용어를 먼저 정리하기

7. Ory Stack 개요

8. 내부 표준 기술

9. 전체 구조 한눈에 보기

10. 사용자 브라우저가 하는 일

11. L7, Nginx, Oathkeeper를 쉽게 이해하기

12. 로그인 흐름(요약)

13. 회원가입 흐름에서 중요한 점

14. 권한 흐름: 로그인과 권한은 다르다

15. RP 통합 방법(개발팀 가이드)

16. 비개발 부서가 알아야 할 통합 체크포인트

17. 보안 및 운영 고려사항

18. 데모 계획

19. 도입 시 역할 분담

20. Q&A 및 다음 단계

13 KiB

Raw Blame History