47 lines
4.2 KiB
JSON
47 lines
4.2 KiB
JSON
{
|
|
"kind": "REFERENCE",
|
|
"title": "OAuth/OIDC 인증 패턴 선택 기준",
|
|
"slug": "oauth-oidc-pattern-selection-criteria",
|
|
"summary": "SPA, Mediator, BFF, OAuth2-Proxy는 브라우저의 access token 사용 여부, Resource Server 호출 주체, server-side 인증 상태, 보호 자원이 검증하는 credential, CSRF 처리 위치가 서로 다르다. 패턴 선택에서는 이 다섯 항목을 요구사항과 운영 환경에 맞춰 비교한다.",
|
|
"purpose": "브라우저에 token이 덜 보이는 순서는 있다. 그 순서를 보안 등급으로 쓰면 판단이 틀린다.\n\nBFF는 브라우저 token을 없애지만 server session과 공유 저장소를 만든다. Forward-Auth는 애플리케이션의 token custody를 줄이지만 edge 헤더 신뢰와 network 경계를 만든다. 새로 생긴 쪽을 감당할 수 없는 환경이면 앞 구조가 더 안전하다.\n\n번호가 아니라 배치를 본다.",
|
|
"rules": [
|
|
{
|
|
"title": "네 축으로 배치를 적는다",
|
|
"body": "구조를 비교할 때는 브라우저 token 전달, Resource Server 호출 주체, server-side 상태, Resource Server의 검증 대상, CSRF 처리 위치를 확인한다.\n\n브라우저가 access token을 받나\nSPA : o Mediator : o BFF : x Forward-Auth : x\n\n브라우저가 보호 자원을 직접 부르나\nSPA : o Mediator : o BFF : x Forward-Auth : x\n\nserver-side token 상태가 있나\nSPA : x Mediator : o BFF : o Forward-Auth : proxy session\n\n보호 자원이 무엇을 검증하나\nSPA : 서명된 JWT Mediator : 서명된 JWT BFF : 서명된 JWT Forward-Auth : edge가 붙인 헤더\n\ncookie가 credential이면 CSRF 검증이 어디에 붙나\nSPA : 해당 없음 Mediator : session endpoint BFF : 상태 변경 endpoint Forward-Auth : proxy cookie 기준\n\n호출 주체와 credential 저장 방식을 정한 뒤에는 401/403, token 갱신 실패, logout을 어느 계층에서 처리할지 정한다."
|
|
},
|
|
{
|
|
"title": "피해야 할 조건을 먼저 확인한다",
|
|
"body": "정책상 브라우저에 token을 둘 수 없으면 memory에만 두는 보관은 답이 아니다. backend 직접 경로나 헤더 덮어쓰기를 닫을 수 없으면 edge에 인증을 맡기지 않는다. 이 조건에 걸리면 다른 항목은 볼 필요가 없다."
|
|
},
|
|
{
|
|
"title": "없앤 것과 새로 맡은 것을 같이 적는다",
|
|
"body": "선택 결과만 적지 않고 어떤 요구에서 해당 패턴을 선택했는지와 적용하기 어려운 조건도 함께 기록한다."
|
|
},
|
|
{
|
|
"title": "이름으로 운영 속성을 추정하지 않는다",
|
|
"body": "BFF나 forward-auth라는 이름은 배치를 말할 뿐이다. 공유 저장소와 장애 복구, session failover, secret 교체가 갖춰져 있는지는 매번 따로 확인한다."
|
|
},
|
|
{
|
|
"title": "옮기는 것은 업그레이드가 아니다",
|
|
"body": "패턴을 바꾸면 credential을 저장하고 전달하고 검증하는 주체도 함께 바뀐다. edge header가 계속 늘어나 애플리케이션 도메인 정보까지 전달해야 한다면 BFF에서 인가와 API 조합을 처리하는 구성을 다시 검토할 수 있다."
|
|
}
|
|
],
|
|
"verifiedOn": null,
|
|
"applyWhen": [
|
|
"인증 구조를 처음 고를 때",
|
|
"한 구조에서 다른 구조로 옮기려 할 때",
|
|
"구조를 문서로 비교할 때",
|
|
"이름만 보고 고른 구조를 다시 검토할 때"
|
|
],
|
|
"exceptions": [
|
|
"요구가 하나로 좁혀지면 비교가 필요 없다. 브라우저에 token을 둘 수 없고 backend가 API를 조합해야 하면 선택지는 하나다.",
|
|
"학습이나 시연이 목적이면 운영 속성 비교를 하지 않아도 된다. 그때는 학습 환경이라고 문서에 적어 둔다."
|
|
],
|
|
"examples": [
|
|
"SPA : 브라우저가 code 교환과 token 보관, API 호출을 모두 맡는다",
|
|
"Mediator : refresh token은 server에 있고 access token은 응답 본문으로 브라우저에 간다",
|
|
"BFF : server가 code 교환·token 관리·API 호출을 담당하고 브라우저는 session cookie로 BFF를 호출한다",
|
|
"Forward-Auth : edge가 인증하고 upstream은 edge가 붙인 헤더를 본다"
|
|
]
|
|
}
|