17 lines
2.5 KiB
JSON
17 lines
2.5 KiB
JSON
{
|
|
"kind": "PROJECT_DECISION",
|
|
"title": "외부 IdP Federation을 별도의 인증 구조로 세지 않는다",
|
|
"slug": "federation-is-not-an-application-pattern",
|
|
"summary": "Google은 upstream IdP, Keycloak은 애플리케이션이 신뢰하는 issuer이자 broker, 네 구조는 애플리케이션 credential 경계다. 세 층을 분리해서 적고 소셜 로그인 추가를 인증 구조 변경으로 세지 않는다.",
|
|
"decisionStatus": "ADOPTED",
|
|
"decidedOn": "2026-08-24",
|
|
"statement": "외부 IdP federation을 다섯 번째 인증 구조로 세지 않는다.\n\nGoogle은 upstream IdP, Keycloak은 애플리케이션이 신뢰하는 issuer이자 broker, 네 구조는 애플리케이션 credential 경계로 각각 분리해 적는다.",
|
|
"rationale": "Google을 구조 하나로 세게 되면 upstream IdP 경계와 애플리케이션 OAuth 경계를 같은 기준으로 묶게 되는데, 두 경계는 검증 방법이 서로 다르다.\n\n사용자가 Keycloak 로그인 화면에서 Google을 고르면 브라우저가 Google authorization endpoint로 이동한다. Keycloak은 Google의 응답을 검증해 local identity와 연결한 뒤 자기 authorization code를 애플리케이션 callback으로 보낸다. 이후 애플리케이션은 Google이 아니라 Keycloak을 상대로 code를 token으로 교환한다.\n\nResource Server가 검증하는 issuer도 브로커이고 애플리케이션은 Google token을 받지 않기 때문에, 소셜 로그인을 붙여도 브라우저가 token을 받는지와 어느 계층이 API를 부르는지는 하나도 바뀌지 않는다.\n\n두 경계를 섞어 두게 되면 비교표에 성격이 다른 항목이 끼어들고, 계정 연결 규칙도 인증 구조 이야기에 섞여서 따로 설계하지 않고 넘어가게 된다.",
|
|
"consequences": [
|
|
"Google을 추가해도 애플리케이션이 검증하는 issuer는 Keycloak으로 유지한다. 네 구조의 credential 배치 기준은 바뀌지 않는다.",
|
|
"계정 연결을 별도 문제로 다뤄야 하고, provider와 upstream subject의 조합을 열쇠로 쓰면서 email이 같다고 자동 병합하지 않는다.",
|
|
"검증 범위를 두 겹으로 적어야 해서 mock provider로 확인한 broker·claim mapping 계약과 실제 계정·공개 HTTPS callback·consent를 구분하게 된다.",
|
|
"upstream IdP가 늘면 브로커 설정이 늘어나게 되어서 그 설정의 소유자를 애플리케이션 팀과 따로 정해야 한다."
|
|
]
|
|
}
|