Perimeter vs Per-Request Auth

auth 체크는 어디서 일어날까? 아키텍처 패턴이 두 개인데, 뭔가 터졌을 때 번지는 범위가 완전히 달라.

패턴	체크 위치	장점	단점
Perimeter	네트워크/프록시 layer (VPN, firewall, reverse proxy)	앱이 auth 알 필요 없음	한 layer = 한 실수로 전체 노출
Per-request	각 앱 안 (middleware, route decorator)	defense in depth. 한 라우트가 뚫려도 다른 라우트는 안 뚫림	로직 반복, 새 엔드포인트에 잊기 쉬움

솔로 개발자 현실: 둘 다, layered

이게 "값싼 자물쇠 두 개" 모델의 이유 전부:

Tailscale = perimeter — tailnet 안 디바이스만 host 도달 가능. (Track 4)
PIN middleware = per-request — tailnet 안 디바이스도 non-public 엔드포인트 치려면 session 쿠키 필요. (Track 5)

per-request auth 어디 둘지

FastAPI, Express, Flask, 어떤 모던 웹 프레임워크든: middleware, 라우트별로 체크하지 마. middleware 는 모든 요청이 핸들러 도달 전에 돌아 — 새 라우트에 추가 잊을 수 없어.

Code

FastAPI middleware 스케치 — 풀버전은 Track 5·python

class PinAuthMiddleware:
    PUBLIC = {"/login", "/health", "/static"}

    async def __call__(self, request, call_next):
        path = request.url.path
        if any(path.startswith(p) for p in self.PUBLIC):
            return await call_next(request)
        if request.client.host in LOCAL_IPS:    # opt-in bypass
            return await call_next(request)
        token = request.cookies.get("session")
        if not token or not is_valid_session(token, request.client.host):
            return RedirectResponse("/login")
        return await call_next(request)

Exercise

네 앱 중 하나에서 라우트 세. 명시적 auth decorator 있는 라우트 세. 그 비율이 middleware 우선인지 decorator 우선인지 말해줄 거야. decorator 쪽이 많으면, 전부를 기본으로 보호하는 middleware 를 짜고 public 라우트만 빠져나가게 해. 기울기를 반대로 뒤집는 거지.

솔로 개발자 현실: 둘 다, layered

per-request auth 어디 둘지

Code

External links

Exercise

Progress

댓글 0