OAuth, OIDC, SAML · sunshinemoon

개념

OAuth, OIDC, SAML은 전부 SSO(Single Sign-On) 맥락에서 나오는 프로토콜인데 하는 일이 조금씩 다르다. OAuth는 "정보 접근 허락"(인가), OIDC는 OAuth 위에 얹은 "로그인"(인증), SAML은 기업 시스템용 XML 기반 인증이다. 이름이 비슷해서 헷갈리지만 인증과 인가를 구분하면 전부 정리된다.

왜 세 개가 필요했나

OAuth — "이 앱이 내 구글 드라이브 읽어도 돼?" 같은 제3자 앱의 리소스 접근 허락이 시작
OIDC — OAuth가 퍼지면서 "로그인 용도로도 쓰자" → 정식 로그인 프로토콜로 확장
SAML — 기업 내부 시스템 시대에 먼저 자리잡은 레거시. XML 기반

그래서 같은 문제(사용자 인증)를 각자 다른 시대에 풀었던 결과물이 공존한다.

OAuth

"이 앱이 내 정보 써도 돼?" 허락을 받는 규칙.

로그인이 아님, 정보 접근 허락만
예: 카카오 정보 제공 동의 화면
핵심 용어: access token = "이 앱이 이 권한을 갖고 있다"는 증명

OIDC

OAuth + "이 사람이 누구인지" 확인 → 로그인.

OAuth 위에 신원 확인 기능을 얹은 것
"카카오로 로그인"이 실제로는 OIDC
가볍고 현대적, JSON 기반
핵심 용어: ID token(JWT) = "이 사람이 누구인지"를 담은 증명

SAML

기업 내부 시스템용 인증 프로토콜.

XML 기반이라 무겁고 복잡
레거시 시스템 연동에 많이 씀
신규 프로젝트는 보통 OIDC로 간다

Keycloak OIDC 로그인 흐름 (Authorization Code Flow)

가장 많이 쓰는 OIDC 흐름. 브라우저가 절대 토큰을 직접 받지 않는 게 포인트다.

1. 브라우저 → Keycloak "로그인할게"
2. Keycloak → 브라우저 "로그인 됐어, 여기 code" (URL 콜백)
3. 브라우저 → 서버 "나 이 code 받았어"
4. 서버 → Keycloak "이 code로 토큰 줘"
5. Keycloak → 서버 "여기 JWT 토큰"
6. 서버 → 브라우저 "로그인 완료"

왜 토큰을 바로 안 주고 code를 먼저 주나

콜백이 브라우저 URL로 오는데 URL은 브라우저 히스토리·로그·referer에 남는다
토큰을 URL에 직접 주면 노출 위험
code는 일회성 임시 교환권. 서버가 code로 Keycloak에 토큰을 요청한다
실제 토큰은 서버 ↔ Keycloak 사이에서만 교환 (브라우저 안 거침)

프로비저닝

SSO 로그인 후 해당 서비스에 유저가 없을 때 자동으로 계정을 만들어주는 것.

1. SSO 로그인 → sid 발급
2. Roundcube 같은 서비스 접속
3. 해당 유저 있나 확인
4. 없으면 → sid로 Keycloak에서 유저 정보 가져와서 자동 계정 생성
5. 있으면 → 그냥 로그인

SSO 환경에서 신규 가입 플로우를 따로 만들지 않는 대신 쓰는 패턴.

개념