SSO 연동의 두 방식: 앱 안의 에이전트(SDK)와 앱 앞의 게이트웨이

상태: 초안 (2026-10-26), 실측 반영. 실측은 셋입니다. ① TT Lab 클러스터의 Keycloak 에서 누구나 읽을 수 있는 공개 메타데이터(/.well-known/openid-configuration, JWKS)를 읽었습니다. 호스트·렐름 이름과 판 번호는 가렸습니다. ② 노트북에 실습용 Keycloak(dev 모드, 운영과 별개인 실습 환경) 을 새로 띄우고 실습 렐름·클라이언트·사용자를 난수 값으로 만들어 Authorization Code + PKCE 를 파이썬 표준 라이브러리만으로 돌렸습니다. 실제 사용자 계정으로는 로그인하지 않았습니다. ③ 실습용 키로 만든 JWT 를 로컬 게이트웨이(agentgateway)에 보내 판정을 봤습니다. 실습 키의 비공개 부분은 글에 넣지 않았습니다. 명세는 같은 날 원문을 열어 확인했습니다. 작성 규칙: 실측 데이터가 기본이고, 못 잰 것은 「미실측」, 확인하지 못한 것은 「확인 못 함」, 짐작은 「추정」으로 적습니다.

목차

• 1. 출입증은 한 곳에서, 확인은 어디서?
• 2. OAuth 2.0, OIDC, SAML: 무엇이 무엇을 푸나
• 3. Authorization Code + PKCE: 토큰이 브라우저를 지나지 않게
  • 세 개의 난수: state, nonce, PKCE
  • 실측: 로컬 Keycloak 으로 한 바퀴
• 4. 토큰 세 가지와 JWT 서명 검증
  • JWT 는 세 조각
  • 서명이 맞아도 끝이 아니다
  • 클러스터 IdP 의 공개 메타데이터
• 5. 에이전트(SDK) 방식: 앱 안의 라이브러리가 하는 일
  • 어떤 라이브러리가 있나, 그리고 Keycloak 어댑터의 퇴장
• 6. 게이트웨이 방식: 앱 앞에서 대신 확인한다
  • 실측: 게이트웨이는 어떤 토큰을 거르나
  • 두 방식의 장단점
• 7. 로그아웃과 세션 동기화
  • 실측: 로그아웃했는데 액세스 토큰은 5분 더 산다
• 8. 흔한 함정
• 9. 어느 쪽을 고를까
• 10. 정리
• 참고

1. 출입증은 한 곳에서, 확인은 어디서?

회사 건물을 떠올려 봅시다. 출입증은 보안실 한 곳에서 발급합니다. 이것이 IdP(Identity Provider, 예: Keycloak)입니다. 출입증을 확인하는 방법은 둘입니다.

• 사무실마다 문에 리더기를 단다. 사무실(애플리케이션)이 스스로 출입증을 읽고, 누가 들어왔는지·무슨 권한인지 직접 압니다. 이것이 에이전트(SDK) 방식입니다. 앱 프로세스 안의 라이브러리가 로그인 리디렉션, 콜백, 세션, 토큰 갱신, 로그아웃을 처리합니다.
• 건물 입구에 경비를 세운다. 입구(게이트웨이)가 출입증을 확인하고, 통과한 사람에게 「이 사람은 누구」라는 쪽지를 붙여 들여보냅니다. 사무실은 쪽지만 읽습니다. 이것이 게이트웨이(프록시) 방식입니다. oauth2-proxy, Envoy 의 JWT 필터, agentgateway 같은 것이 앱 앞에서 일을 맡습니다.

두 방식은 같은 규약(OIDC) 을 씁니다. 다른 것은 그 규약을 어느 프로세스가 수행하느냐뿐입니다. 그래서 먼저 규약을 보고(2–4절), 그것을 앱 안에서 할 때(5절)와 앱 앞에서 할 때(6절)를 비교한 다음, 로그아웃(7절)과 함정(8절)으로 갑니다.

2. OAuth 2.0, OIDC, SAML: 무엇이 무엇을 푸나

OAuth 2.0 만으로는 「로그인」이 안 된다는 점이 중요합니다. 액세스 토큰은 API 를 위한 것이지 「누가 로그인했는지」를 앱에 증명하는 문서가 아니기 때문입니다. OIDC 가 그 빈칸을 ID 토큰으로 메웁니다. OIDC Core §2 는 ID 토큰에 iss·sub·aud·exp·iat 를 반드시 넣게 합니다.

SAML 의 SP 시작 흐름도 모양은 비슷합니다. SP(앱)가 AuthnRequest 를 압축해 리디렉트로 보내고, IdP 가 로그인시킨 뒤 서명된 Response 를 HTML 폼의 POST 로 앱의 ACS 주소에 넘깁니다(OASIS SAML 2.0 기술 개요 §5.1.2, §4.6). 이 글은 새로 만드는 연동에서 주로 쓰는 OIDC 를 중심으로 봅니다. SAML 의 규범 문서(core·bindings PDF)는 본문을 직접 인용하지 못했고, 개요 문서로 확인했습니다.

3. Authorization Code + PKCE: 토큰이 브라우저를 지나지 않게

흐름의 핵심은 브라우저를 통해서는 짧게 사는 code 만 건너가고, 토큰은 앱과 IdP 가 뒤채널로 직접 주고받는다는 것입니다. 브라우저 주소창, 히스토리, 리퍼러, 확장 프로그램은 모두 새는 곳이기 때문입니다. 예전의 implicit 흐름은 토큰을 주소의 #fragment 로 브라우저에 바로 줬고, OAuth 보안 BCP(RFC 9700, 2025-01) §2.1.2 는 이제 implicit 을 쓰지 말라고 합니다. 같은 문서는 비밀번호를 앱이 받아 IdP 에 넘기는 password grant 도 금지(§2.4)합니다.

세 개의 난수: state, nonce, PKCE

로그인 요청 하나에 난수가 셋 붙습니다. 하는 일이 서로 다릅니다.

PKCE(RFC 7636)의 계산은 한 줄입니다. 앱이 43–128자의 난수 code_verifier 를 만들고(§4.1), 로그인 요청에는 그 해시 code_challenge = BASE64URL(SHA256(code_verifier)) 만 보냅니다(§4.2, S256). code 를 토큰으로 바꿀 때 원래 verifier 를 내야 하므로, code 만 훔친 쪽은 아무것도 못 합니다.

import base64, hashlib, secrets
b64u = lambda b: base64.urlsafe_b64encode(b).rstrip(b"=").decode()
verifier = b64u(secrets.token_bytes(32))                       # 43자
challenge = b64u(hashlib.sha256(verifier.encode()).digest())
print(b64u(hashlib.sha256(b"dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk").digest()))

마지막 줄은 RFC 7636 부록 B 의 예제 verifier 입니다. 로컬에서 돌리니 E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM 로, 부록의 기대값과 같았습니다(2026-10-26). RFC 9700 §2.1.1 은 공개 클라이언트(비밀을 못 지키는 SPA·모바일 앱)는 PKCE 를 반드시 쓰라고 하고, 비밀이 있는 서버 앱에도 권합니다.

실측: 로컬 Keycloak 으로 한 바퀴

실습용 Keycloak 에 비밀을 가진(confidential) 클라이언트 하나를 만들고, PKCE 를 S256 으로 강제하고, redirect URI 를 정확히 하나만 등록했습니다. 그다음 브라우저 역할을 파이썬 urllib 로 흉내 내어 위 그림의 ③–⑨ 를 그대로 밟았습니다.

콜백에 iss 가 붙어 오는 것은 IdP 가 authorization_response_iss_parameter_supported 를 켠 덕분입니다. 앱이 IdP 를 여럿 쓸 때 「이 code 를 어느 IdP 가 보냈나」를 헷갈리게 만드는 혼동 공격(mix-up)을 막습니다.

한 가지는 예상보다 셌습니다. 같은 code 를 다시 쓰자, 그 code 로 이미 받아 둔 토큰의 세션까지 끊겼습니다. 재사용 시도 직후 그 세션의 액세스 토큰을 introspection 하면 active: false, 리프레시 토큰으로 갱신하면 400 「Session doesn't have required client」였습니다. code 가 두 번 쓰였다는 것은 누군가 code 를 가로챘다는 신호이므로, 이미 나간 토큰도 믿지 않겠다는 동작입니다. RFC 6749 §4.1.2 가 권하는 바로 그 처리입니다. 다만 그 액세스 토큰은 서명 검증만 하는 쪽에서는 여전히 유효했습니다(7절의 문제와 같습니다).

4. 토큰 세 가지와 JWT 서명 검증

액세스·ID 토큰은 쿠키 하나(보통 4KB 한도)의 3분의 1 이상을 차지합니다. 게이트웨이가 토큰을 쿠키에 넣는 방식이면 여러 쿠키로 쪼개거나 서버 쪽 세션 저장소를 써야 하는 이유입니다.

JWT 는 세 조각

JWT(RFC 7519)는 JWS(RFC 7515)의 압축 형식으로 BASE64URL(헤더).BASE64URL(페이로드).BASE64URL(서명) 입니다. base64url 은 암호화가 아닙니다. 누구나 디코드해서 읽을 수 있으므로 토큰에 비밀을 넣으면 안 됩니다. 실측한 토큰의 헤더는 {"alg":"RS256","typ":"JWT","kid":"…"} 였고, kid 는 IdP 의 공개키 목록(JWKS, RFC 7517)에서 어느 키로 검증할지 고르는 이름표입니다.

RS256 검증은 결국 거듭제곱 한 번입니다. 서명 s 를 공개키 (n, e) 로 s^e mod n 하면 PKCS#1 v1.5 모양(00 01 FF … FF 00 + DigestInfo + SHA-256(헤더.페이로드))이 나와야 합니다. 이해를 위해 표준 라이브러리로 직접 써 봤습니다(운영 코드에서는 검증된 라이브러리를 쓰십시오).

def rs256_ok(token, jwk):
    h64, p64, s64 = token.split(".")
    n = int.from_bytes(ub64(jwk["n"]), "big"); e = int.from_bytes(ub64(jwk["e"]), "big")
    k = (n.bit_length() + 7) // 8
    em = pow(int.from_bytes(ub64(s64), "big"), e, n).to_bytes(k, "big")
    di = bytes.fromhex("3031300d060960864801650304020105000420") + hashlib.sha256(f"{h64}.{p64}".encode()).digest()
    return em == b"\x00\x01" + b"\xff" * (k - 3 - len(di)) + b"\x00" + di

실측: 실습 IdP 가 준 액세스·ID·로그아웃 토큰 모두 JWKS 의 2048비트 RSA 키로 이 함수를 통과했고, 페이로드 한 비트만 바꾸면 실패했습니다.

서명이 맞아도 끝이 아니다

서명은 「IdP 가 만들었다」만 증명합니다. 「나에게, 지금, 이 로그인으로 온 토큰인가」는 클레임으로 따로 확인해야 합니다. OIDC Core §3.1.3.7 이 ID 토큰 검증을 13단계로 적어 두었고, 핵심은 그림의 4–7번입니다. iss 는 글자까지 같아야 하고, aud 에 내 client_id 가 있어야 하고, exp 가 지나지 않았어야 하고, nonce 가 내가 보낸 값이어야 합니다. JWT 모범 사례(RFC 8725)는 라이브러리가 받아들일 알고리즘 목록을 호출자가 정하게 하라(§3.1), aud 를 반드시 검사하라(§3.9)고 합니다. alg: none 은 「명시적으로 요청하지 않는 한 받지 말라」(SHOULD NOT, §3.2)입니다.

실측한 토큰에서 함정 둘이 보였습니다.

1. Keycloak 액세스 토큰의 aud 는 기본으로 account 였습니다. 내 API 의 이름이 아닙니다. API 쪽에서 aud 를 제대로 검사하려면 IdP 에 audience 매퍼를 붙여 API 이름이 들어가게 해야 합니다. 귀찮다고 API 에서 aud 검사를 끄면, 같은 IdP 가 다른 앱에 준 토큰으로 내 API 를 부를 수 있게 됩니다.
2. JWT 액세스 토큰 표준(RFC 9068)은 헤더 typ 을 at+jwt 로 하라고 하는데, 실측 토큰은 JWT 였습니다(클레임 typ 은 Bearer). RFC 9068 §4 대로 typ 을 엄격히 보는 리소스 서버라면 이 토큰을 거절합니다. 어느 쪽을 맞출지 연동 전에 정해야 합니다.

exp 에는 시계 오차 허용(leeway)이 붙습니다. RFC 7519 §4.1.4 는 「보통 몇 분을 넘지 않는 작은 여유」를 허용합니다. 실측 ID 토큰을 만료 1초 뒤의 시계로 검사하면 여유 없이는 exp 실패, 60초 여유로는 통과였습니다. Spring Security 리소스 서버의 기본 여유가 60초(공식 문서)이고, 6절의 게이트웨이도 실측으로 약 60초였습니다.

클러스터 IdP 의 공개 메타데이터

TT Lab 클러스터의 Keycloak 에서 Discovery 문서와 JWKS 를 읽었습니다(2026-10-26). 둘 다 인증 없이 열리는 공개 정보이고, 아래 값은 Keycloak 이 렐름마다 기본으로 내놓는 목록입니다.

여기서 볼 점은 Discovery 문서는 서버가 「할 수 있는 것」의 목록이지, 클라이언트에 「허용된 것」이 아니라는 것입니다. implicit·password·plain 이 목록에 있어도 클라이언트별로 끌 수 있고, 꺼야 합니다. 클라이언트마다 표준 흐름(code)만 켜고 implicit·직접 접근(password) 흐름은 끄는 것이 기본 자세입니다.

5. 에이전트(SDK) 방식: 앱 안의 라이브러리가 하는 일

앱 안의 OIDC 라이브러리는 위 3–4절을 전부 대신합니다. 목록으로 적으면 생각보다 깁니다.

1. 시작할 때 Discovery 문서를 읽고 JWKS 를 받아 캐시한다. 모르는 kid 가 오면 다시 받는다(횟수 제한을 두고).
2. 보호된 경로에 세션 없이 오면 state·nonce·verifier 를 만들어 서버 쪽 세션에 저장하고 IdP 로 리디렉트한다.
3. 콜백에서 state 를 대조하고, code 와 verifier 로 토큰을 받고, ID 토큰을 검증한다.
4. 앱 세션 쿠키(HttpOnly·Secure·SameSite)를 발급한다. 토큰은 서버에 둔다.
5. 액세스 토큰이 만료되기 전에 리프레시 토큰으로 갱신한다. 실패하면 다시 로그인시킨다.
6. 로그아웃: 앱 세션을 지우고, IdP 의 end_session_endpoint 로 보낸다(RP-Initiated Logout). IdP 가 보내는 백채널 로그아웃 요청을 받을 엔드포인트도 연다(7절).
7. API 를 제공하는 쪽(리소스 서버)이면 들어오는 Bearer 토큰의 서명·iss·aud·exp 를 검사한다.

로컬 실측에서 파이썬으로 이 과정을 흉내 낸 코드가 약 150줄이었고, 그마저 세션 저장, 키 회전, 동시성은 빠져 있습니다. 직접 짜지 말고 검증된 라이브러리를 쓰는 이유입니다.

어떤 라이브러리가 있나, 그리고 Keycloak 어댑터의 퇴장

예전에는 Keycloak 이 언어별 어댑터를 직접 냈습니다. 지금은 대부분 사라졌습니다. 공식 블로그를 따라가면 순서는 이렇습니다.

이 흐름의 의미는 분명합니다. IdP 회사가 언어마다 SDK 를 붙들고 있을 필요가 없을 만큼 OIDC 가 표준화됐다는 것입니다. 자바라면 Spring Security 가 대표입니다.

# 로그인(oauth2Login) — 앱이 OIDC 클라이언트가 된다
spring.security.oauth2.client.provider.idp.issuer-uri: https://<IdP>/realms/<렐름>
spring.security.oauth2.client.registration.idp: { client-id: <앱>, client-secret: <비밀>, scope: [openid, profile] }
# 토큰 검사(oauth2ResourceServer) — API 가 Bearer 를 검증한다
spring.security.oauth2.resourceserver.jwt.issuer-uri: https://<IdP>/realms/<렐름>

issuer-uri 하나로 Discovery 문서에서 JWKS 주소를 찾아오고(첫 요청 때), 시계 여유는 60초가 기본입니다(Spring Security 문서). Spring Boot 4.x 에서는 스타터 이름이 spring-boot-starter-security-oauth2-client·…-resource-server 로 바뀌고 옛 이름은 폐기 예정입니다. 로그인한 사용자의 인가된 클라이언트(토큰)는 기본으로 메모리의 OAuth2AuthorizedClientService 에 둡니다. 세션에 두는 것은 익명 요청뿐입니다. 앱을 여러 대로 늘리면 이 저장소를 공유 저장소로 바꿔야 합니다.

Argo CD, Grafana, Harbor, Gitea 같은 제품은 안에 OIDC 클라이언트가 들어 있어서 설정에 IdP 주소와 클라이언트 비밀만 넣으면 됩니다. 이것도 에이전트 방식입니다. 라이브러리를 우리가 넣었느냐, 제품이 넣어 왔느냐의 차이일 뿐입니다.

6. 게이트웨이 방식: 앱 앞에서 대신 확인한다

앱을 고칠 수 없거나(남이 만든 대시보드), 언어가 제각각인 서비스가 여럿이면 입구에서 한 번에 처리하는 편이 낫습니다. 게이트웨이가 하는 일은 두 갈래입니다.

• 로그인까지 대신하는 프록시: oauth2-proxy 가 대표입니다. 브라우저를 IdP 로 보내고, 콜백을 받고, 결과를 쿠키 세션(기본은 쿠키에 담고, Redis 로 바꿀 수 있음)으로 들고 있습니다. nginx 의 auth_request 처럼 「이 요청을 들여보내도 되나」만 묻는 용도로 /oauth2/auth 를 쓰면 202 또는 401 만 돌려줍니다. 통과한 요청에는 X-Auth-Request-User·-Email·-Groups 같은 헤더나 Authorization: Bearer <토큰> 을 붙여 넘깁니다(공식 문서).
• 토큰 검사만 하는 프록시: Envoy 의 jwt_authn 필터, agentgateway 의 jwtAuth 처럼 이미 Bearer 토큰을 가진 클라이언트(다른 서비스, CLI, 에이전트)의 요청을 검사합니다. Envoy 는 원격 JWKS 를 기본 10분 캐시합니다(공식 문서).

두 갈래를 겹쳐 쓰는 구성도 흔합니다. 로그인 프록시가 PKCE 로 로그인시키고 IdP 의 그룹 클레임으로 들어올 사람을 거른 뒤 토큰을 Authorization 헤더로 붙이면, 그 뒤의 서비스 메시가 같은 JWT 를 다시 검사하는 식입니다. 이때 원칙은 하나입니다. 프록시의 쿠키 갱신 주기는 IdP 의 액세스 토큰 수명보다 짧게, 쿠키 만료는 IdP 의 SSO 세션 최대 길이를 넘지 않게 둡니다. 그래야 뒤에서 JWT 를 검사하는 쪽이 만료된 토큰을 보기 전에 프록시가 새 토큰을 받아 두고, IdP 에서 세션이 끝난 사람이 쿠키만으로 계속 들어오지 못합니다. oauth2-proxy 의 공식 설정 표에서 쿠키 갱신(cookie_refresh)은 기본값이 비어 있고 0 이면 꺼지며, 쿠키 만료(cookie_expire)의 기본값은 168시간(7일)입니다. 토큰을 뒤로 넘기는 구성이라면 둘 다 IdP 설정에 맞춰 직접 정해야 합니다.

실측: 게이트웨이는 어떤 토큰을 거르나

실습용 RSA 키로 JWT 를 만들어, jwtAuth(strict, iss·aud 지정, JWKS 파일) 를 켠 agentgateway 를 로컬에 띄우고 요청을 한 건씩 보냈습니다(2026-10-26).

마지막 줄이 흥미롭습니다. 만료를 10·30·55·58·62·65·90·120초 전으로 바꿔 보니 58초까지는 통과, 62초부터 거절이었습니다. nbf 도 55초 뒤까지는 통과, 65초 뒤부터 거절이었습니다. 앞뒤 약 60초의 시계 여유가 기본으로 들어 있다는 뜻입니다(문서에서는 확인 못 함, 실측). 만료를 「정확히 그 초」로 믿고 설계하면 안 되는 이유입니다.

비용도 쟀습니다. 같은 백엔드를 직접 부를 때, 인증 없는 게이트웨이를 거칠 때, JWT 검사 게이트웨이를 거칠 때를 400번씩 번갈아 불렀습니다(예열 50번 뒤).

게이트웨이 한 번을 더 거치는 값(약 1.9ms, 노트북의 컨테이너 망 왕복 포함)에 비해 RS256 검증 자체는 약 0.08ms 였습니다. 검증 비용 때문에 게이트웨이를 망설일 일은 없습니다.

두 방식의 장단점

현실에서는 섞어 씁니다. 브라우저 로그인은 게이트웨이(또는 BFF)가, API 의 세밀한 권한은 앱 안의 리소스 서버 라이브러리가 맡는 식입니다.

7. 로그아웃과 세션 동기화

SSO 의 로그아웃이 어려운 이유는 세션이 세 겹이기 때문입니다. IdP 의 SSO 세션(IdP 쿠키), 앱의 세션(앱 쿠키), 그리고 이미 발급되어 각자 들고 있는 토큰입니다. 하나만 지우면 나머지가 남습니다.

실측: 로그아웃했는데 액세스 토큰은 5분 더 산다

실습 IdP 의 클라이언트에 백채널 로그아웃 주소를 등록하고(노트북에서 받는 작은 HTTP 서버), 새로 로그인한 뒤 리프레시 토큰으로 로그아웃을 요청했습니다.

마지막 줄이 핵심입니다. JWT 액세스 토큰은 스스로 증명하는 문서라서, 서명만 보는 API 와 게이트웨이는 IdP 가 세션을 지운 것을 모릅니다. 로그아웃 뒤에도 토큰 수명만큼(여기서는 5분) API 를 부를 수 있습니다. 대응은 셋 중 하나입니다. 액세스 토큰 수명을 짧게 하거나, 중요한 API 는 introspection 으로 IdP 에 물어보거나(매 요청 왕복 비용), 백채널 통지를 받아 그 sid 를 차단 목록에 올립니다.

리프레시 토큰도 비슷한 고민이 있습니다. 실습 렐름의 기본값(회전 꺼짐)에서는 이미 한 번 쓴 리프레시 토큰을 다시 써도 200 이었습니다. 렐름 설정 revokeRefreshToken 을 켜자(회전), 옛 리프레시 토큰은 400 「Maximum allowed refresh token reuse exceeded」로 거절됐고, 그 직후 새 리프레시 토큰까지 「Session doesn't have required client」로 막혔습니다. 재사용을 도난의 신호로 보고 그 세션 전체를 끊는 동작입니다. RFC 9700 §2.2.2 는 공개 클라이언트의 리프레시 토큰은 회전하거나 송신자에 묶으라고 합니다.

8. 흔한 함정

① redirect_uri 불일치. IdP 는 등록된 주소와 문자열로 정확히 비교합니다(RFC 9700 §2.1, 네이티브 앱의 localhost 포트만 예외). 실측에서 끝의 / 하나로 400 화면이 떴습니다. 프록시 뒤에서 앱이 자기 주소를 http:// 로 알고 있거나(TLS 를 앞에서 끝낸 경우), 포트·경로 접두사가 다르면 같은 오류가 납니다. 와일드카드 redirect URI 는 공격자가 code 를 자기 쪽 경로로 받게 만드는 길이 되므로 쓰지 않습니다.

② iss 글자 불일치. 토큰의 iss 와 앱 설정의 issuer 가 http/https, 호스트 이름, 끝의 / 까지 같아야 합니다. IdP 를 내부 주소로 부르고 브라우저는 공개 주소로 가는 구성에서 특히 자주 깨집니다. Keycloak 은 요청받은 호스트 이름으로 iss 를 만들 수 있으므로, 고정된 공개 호스트 이름을 설정해 두는 편이 안전합니다.

③ 시계 어긋남. IdP·게이트웨이·앱 서버의 시계가 다르면 막 받은 토큰이 「아직 유효하지 않음」(nbf·iat)이나 「만료됨」이 됩니다. 실측한 기본 여유는 게이트웨이·Spring 모두 약 60초였습니다. 여유를 늘리기 전에 NTP 부터 맞춥니다.

④ 토큰을 브라우저 저장소에 둔다. SPA 가 액세스·리프레시 토큰을 localStorage 에 두면 XSS 한 번에 통째로 나갑니다. 2026-08 에 RFC 10017(BCP 212)이 된 「브라우저 기반 앱을 위한 OAuth 2.0」은 패턴을 보안 순서로 BFF(Backend for Frontend) → 토큰 중개 백엔드 → 브라우저 단독으로 늘어놓고, 브라우저 단독은 앞서 논한 모든 공격에 취약하다고 적습니다. BFF 는 비밀을 가진 서버 쪽 클라이언트로서 토큰을 서버에 두고 브라우저에는 HttpOnly 세션 쿠키만 줍니다. 즉 5절의 SDK 방식을 서버에서 하는 것입니다.

⑤ aud 를 안 본다. 4절의 Keycloak 기본 aud: account 처럼 토큰의 대상이 내 API 가 아닌데도 받아 주면, 같은 IdP 의 다른 앱 토큰으로 내 API 를 부를 수 있습니다.

⑥ Secure 쿠키와 평문 http. IdP 의 로그인 쿠키에는 Secure 가 붙어 있습니다(실측). 브라우저는 localhost·127.0.0.1 은 안전한 출처로 보고 보내 주지만, LAN 의 평문 http 주소에서는 보내지 않아 「로그인했는데 다시 로그인 화면」이 반복됩니다. 실측 중 파이썬 쿠키 저장소가 같은 이유로 쿠키를 안 보내 400 을 받았습니다.

⑦ JWKS 키 회전. IdP 가 키를 바꾸면 새 kid 의 토큰이 옵니다. 캐시를 오래 들고 있는 검증기(Envoy 기본 10분)는 그동안 거절할 수 있으므로, IdP 는 새 키를 먼저 공개하고 한참 뒤에 서명에 쓰고, 검증기는 모르는 kid 에서 JWKS 를 다시 받게 합니다.

⑧ 게이트웨이 우회와 헤더 위조. 게이트웨이 방식에서 앱이 X-Auth-Request-User 를 믿는다면, 그 헤더를 바깥에서 넣어 앱을 직접 부르는 길이 없어야 합니다.

9. 어느 쪽을 고를까

10. 정리

• SSO 연동은 「같은 OIDC 를 누가 수행하느냐」의 문제입니다. 앱 안의 라이브러리(에이전트·SDK)든 앱 앞의 프록시(게이트웨이)든, 하는 일은 리디렉트, PKCE, code 교환, 서명·클레임 검사, 세션, 갱신, 로그아웃으로 같습니다.
• 서명은 출처만 증명합니다. iss·aud·exp·nonce 는 따로 봐야 하고, 실측한 Keycloak 액세스 토큰은 기본 aud 가 API 이름이 아니었습니다.
• 로그아웃은 세 겹입니다. 실측에서 백채널 통지는 66ms 만에 왔지만, 서명만 보는 쪽에서는 액세스 토큰이 남은 5분 동안 그대로 통했습니다.
• Keycloak 의 언어별 어댑터는 23·25판에서 사라졌고, 이제는 각 플랫폼의 표준 OIDC 지원을 씁니다.

티티 한마디. 출입증(토큰)에 도장(서명)이 찍혀 있어도, 「우리 탁구장 거」(aud)인지, 「오늘 날짜」(exp)인지는 따로 봐야 해요. 그리고 퇴장시켜도 손에 든 출입증은 유효기간까지 살아 있으니, 짧게 끊어 주는 게 좋아요.

참고

• RFC 6749, OAuth 2.0. §4.1.2(code 재사용 시 이미 발급한 토큰 폐기 권고). https://www.rfc-editor.org/rfc/rfc6749.html
• RFC 7636, PKCE. §4.1·§4.2·부록 B. https://www.rfc-editor.org/rfc/rfc7636.html
• RFC 9700, OAuth 2.0 Security Best Current Practice(2025-01). §2.1·§2.1.1·§2.1.2·§2.2.2·§2.4. https://www.rfc-editor.org/rfc/rfc9700.html
• RFC 10017, OAuth 2.0 for Browser-Based Applications(BCP 212, 2026-08). §5·§6. https://www.rfc-editor.org/rfc/rfc10017.html
• RFC 7519(JWT) §4.1.4·§4.1.5, RFC 7515(JWS) §3.1·§7.1, RFC 7517(JWK) §4.5·§5, RFC 8725(JWT BCP) §3.1·§3.2·§3.9, RFC 7662(introspection) §2.1·§2.2, RFC 9068(JWT 액세스 토큰) §2.1·§4. https://www.rfc-editor.org/
• OpenID Connect Core 1.0 §2·§3.1.2.1·§3.1.3.7 https://openid.net/specs/openid-connect-core-1_0.html · Discovery 1.0 §4 https://openid.net/specs/openid-connect-discovery-1_0.html · Back-Channel Logout 1.0 §2.4·§2.5 https://openid.net/specs/openid-connect-backchannel-1_0.html · Front-Channel Logout https://openid.net/specs/openid-connect-frontchannel-1_0.html · RP-Initiated Logout https://openid.net/specs/openid-connect-rpinitiated-1_0.html
• OASIS, SAML V2.0 Technical Overview §4.6·§5.1.2. https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
• Keycloak 블로그: 어댑터 폐기(2022-02) https://www.keycloak.org/2022/02/adapter-deprecation · 갱신(2023-03) https://www.keycloak.org/2023/03/adapter-deprecation-update · 23.0.0 https://www.keycloak.org/2023/11/keycloak-2300-released · 25.0.0 https://www.keycloak.org/2024/06/keycloak-2500-released.html · keycloak-js 분리(2025-02) https://www.keycloak.org/2025/02/keycloak-js-2620-released
• Spring Security 리소스 서버 JWT(시계 여유 60초) https://docs.spring.io/spring-security/reference/servlet/oauth2/resource-server/jwt.html · OAuth2 클라이언트 핵심 https://docs.spring.io/spring-security/reference/servlet/oauth2/client/core.html · Spring Boot 스타터 https://docs.spring.io/spring-boot/reference/using/build-systems.html
• oauth2-proxy: 엔드포인트 https://oauth2-proxy.github.io/oauth2-proxy/features/endpoints · 설정(cookie_refresh·cookie_expire 기본값) https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview
• Envoy jwt_authn(cache_duration 기본 10분) https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/jwt_authn/v3/config.proto
• 모든 원문은 2026-10-26 에 열어 확인했습니다.