OAuth로 로그인을 붙일 때, 클라이언트 등록은 보통 이렇게 시작합니다. 인가 서버 콘솔에 앱을 미리 등록하고 client_id를 발급받아 코드에 박아 두는 거죠. 클라이언트와 서버가 서로를 아는 고정된 관계라 이 방식으로 충분했습니다. 그런데 이 전제가 통하지 않는 세계가 있습니다. 클라이언트와 서버가 처음 만나는 게 일상인 개방형 생태계예요. "Bluesky로 로그인"하는 서드파티 앱이 사용자마다 다른 서버에 붙고, AI 에이전트가 그날 처음 발견한 도구 서버에 연결하는 식이죠. 미리 등록할 시간도, 모두를 아우르는 중앙 등록
MCP 서버를 직접 만들어 보신 적 있으신가요? 처음에는 로컬에서 STDIO로 붙여서 쓰다가, 원격으로 배포하려는 순간 고민이 시작되는데요. "아무나 내 MCP 서버를 호출하면 안 되는데, 누가 접근할 수 있는지 어떻게 가리지?"라는 질문이 떠오르거든요 🤔 이 질문에 대한 공식 답변이 바로 MCP 스펙의 Authorization 섹션입니다. 2025년 11월 25일 개정판에서는 OAuth 2.1을 기반으로 여러 RFC를 조합한 인증 방식을 정리했는데요. 얼핏 보면 OAuth 2.1, RFC 7591, RFC 8414, RFC 87
회사 내부용 대시보드나 관리자 페이지를 외부에 공개해야 할 때 어떻게 하시나요? 사내 VPN으로 감싸자니 외부 협업자에게 계정을 만들어 줘야 하고, IP 화이트리스트로 막자니 재택근무 환경에서 자꾸 IP가 바뀌어 곤란하죠. 그렇다고 아예 공개 URL로 두고 로그인 화면을 직접 구현하자니 인증 로직을 매번 새로 붙여야 하니 배보다 배꼽이 더 큽니다 😅 Cloudflare Access는 이런 고민을 엣지에서 해결해 주는 ZTNA(Zero Trust Network Access) 서비스입니다. 원본 애플리케이션에 손대지 않고도 요청이 C
앱에 인증을 붙일 때 우리는 보통 한 방향만 생각합니다. 구글이나 회사 SSO 같은 외부 신원 제공자에 "우리 사용자 좀 로그인시켜 주세요" 하고 기대는 쪽이죠. WorkOS로 엔터프라이즈 SSO 붙이기에서 다룬 게 딱 이 방향입니다. 그런데 서비스가 자리를 잡으면 반대 요구가 들어오기 시작해요. "당신 서비스의 계정으로 우리 앱에 로그인하게 해주세요", "그 사용자의 데이터를 API로 가져가게 해주세요" 하고 이번엔 다른 앱들이 우리에게 기대오는 겁니다. "Google로 로그인"이나 "GitHub로 로그인" 버튼을 우리 서비스 이
OAuth 2.0 스펙은 /authorize나 /token 같은 엔드포인트가 존재해야 한다고는 말하지만, 실제로 어떤 경로에 두어야 하는지는 정하지 않습니다. 그래서 한동안 관행은 단순했어요. "구글은 accounts.google.com/o/oauth2/v2/auth, GitHub는 github.com/login/oauth/authorize" 같은 정보를 사람이 공식 문서에서 읽어다가 클라이언트 코드에 박아 넣는 방식이었죠. 이 방식은 금방 한계를 드러냈어요. 새로운 신원 공급자(Identity Provider, 이하 IdP)를 추
OAuth 연동을 만들 때 보통 가장 먼저 하는 일은 인가 서버(Authorization Server, 이하 AS)에 애플리케이션을 등록하는 것입니다. 관리 콘솔에 들어가 앱 이름, 리다이렉트 URI, 로고, 권한 범위를 입력하고 client_id와 client_secret을 발급받죠. 구글이나 GitHub처럼 정해진 제공자 한두 곳만 상대한다면 이 방식으로 충분합니다. 그런데 클라이언트와 AS가 미리 서로를 알 수 없는 환경이라면 이야기가 달라집니다. 사용자가 처음 보는 MCP 서버에 AI 클라이언트를 붙이거나, 여러 테넌트가 각
지금까지 OAuth를 이야기할 때는 늘 사용자가 주인공이었습니다. 인가 코드(Authorization Code) + PKCE 흐름에서 봤듯이, 사용자가 로그인하고 동의하면 그 사용자를 대신할 토큰이 발급되는 식이었죠. 그런데 현실에는 로그인할 사람이 아예 없는 통신도 많습니다. 새벽 3시에 도는 결제 배치 작업이 결제 API를 호출하고, 백엔드 서비스 A가 내부 서비스 B의 API를 두드리고, CI 파이프라인이 배포 API를 부르는 상황을 떠올려 보세요. 여기엔 브라우저도, 동의 화면도, 사용자도 없습니다. 이렇게 서버가 서버를 부
OAuth 2.0을 처음 배울 때는 "인가 코드(authorization code)를 받아서 액세스 토큰(access token)으로 바꾼다"는 큰 그림만 머리에 담아두어도 충분한데요. 하지만 실제로 연동을 구현하거나 디버깅하는 단계로 넘어가면, 어떤 엔드포인트에 어떤 파라미터를 어떤 조건으로 보내야 하는가가 성패를 좌우합니다. "동의 화면까지는 뜨는데 토큰 교환에서 invalid_grant가 뜬다", "리다이렉트가 자꾸 invalid_redirect_uri로 거부된다" 같은 이슈는 거의 전부 특정 엔드포인트의 파라미터 규약을 놓쳐
OAuth를 배우다 보면 결국 이 문장을 자주 만나게 됩니다. 사용자 로그인이 있으면 인가 코드(Authorization Code) + PKCE를 쓰세요. 맞는 말인데, 처음 구현할 때는 막상 손에 잘 잡히지 않습니다. code는 어디서 오고, code_verifier는 누가 들고 있어야 하고, state는 PKCE와 다른 건지 헷갈리거든요. 동의 화면까지는 잘 뜨는데 콜백에서 invalid_grant가 나거나, 토큰 교환에서 redirect_uri가 다르다고 거부되는 일도 흔합니다. 이 글에서는 인가 코드 + PKCE 흐름을 요청
OAuth를 공부하다 보면 "인가 코드 흐름(Authorization Code Flow)을 써라", "클라이언트 자격 증명(Client Credentials)은 서버 간 통신용이다", "암묵적 흐름(Implicit)은 이제 쓰지 마라" 같은 말을 자주 듣게 됩니다. 처음에는 다 같은 OAuth처럼 보이는데, 왜 이렇게 flow가 여러 개인지 헷갈리기 쉽죠. 사실 스펙 관점에서 더 정확한 이름은 흐름(flow)보다 **그랜트 유형(grant type)**입니다. 클라이언트가 어떤 근거(grant)를 가지고 액세스 토큰(access t
이번 글에서는 NestJS에서 API의 버전을 체계적으로 관리하는 방법에 대해서 배워보도록 하겠습니다. API Versioning이란? REST API와 같은 서버 애플리케이션을 운영하다 보면, 부득이하게 클라이언트에 큰 영향을 줄 수 있는 위험한 변경을 해야 할 때가 있는데요. API Versioning, 즉 버전 관리를 통해서, 우리는 서버 측 API 변경에 따른 클라이언트의 영향을 최소화하고, API의 호환성과 안정성을 높일 수 있습니다. 버전 관리가 이루어지는 API는 보통 클라이언트에게 v1, v2, v3... 이런 식으로
이번 글에서는 가드(Guard)를 활용하여 NestJS 앱을 위험한 요청으로 부터 효과적으로 보호하는 방법에 대해서 배워보도록 하겠습니다. 가드(Guard)란? NestJS에서 가드(guard)란 애플리케이션의 최전선에서 말그대로 애플리케이션을 보호하는 역할을 담당하는데요. NestJS로 들어오는 요청은 컨트롤러(controller) 단에 도달하기 전에 반드시 가드를 거쳐가도록 되어 있습니다. 가드를 이용하면 컨트롤러가 요청을 처리하기 전에 안전하지 않은 요청을 효과적으로 차단할 수 있습니다. 따라서 애플리케이션 보안을 위해서 필수
이번 포스팅에서는 자바스크립트로 어떻게 JWT 토큰을 발급하고 검증하는지에 대해서 알아보겠습니다. jsonwebtoken 패키지 설치 우선 Node.js의 패키지 매니저인 npm을 이용하여 jsonwebtoken 패키지를 설치하겠습니다. jsonwebtoken는 JWT 표준 명세서를 자바스크립트 언어로 구현하고 있는 라이브러리입니다. 따라서 JWT 기반으로 사용자 인증이나 인가를 하는 자바스크립트 서버 애플리케이션에서는 직접적으로든 간접적으로든 (passport-jwt와 같은 프레임워크를 통해서) jsonwebtoken 라이브러리를
이번 포스팅에서는 Json Web Token, 줄여서 흔히 JWT라고 불리는 사용자 인증/인가 수단 대해서 알아보도록 하겠습니다. JWT 란? JWT(Json Web Token)는 말그대로 웹에서 사용되는 JSON 형식의 토큰에 대한 표준 규격인데요. RFC 7519로 정의되어 있으며, 토큰을 어떤 구조로 만들고 어떻게 서명하는지, 그리고 안에 담을 수 있는 표준 클레임(claim)에는 어떤 것들이 있는지를 규정합니다. 주로 사용자의 인증(authentication) 또는 인가(authorization) 정보를 서버와 클라이언트 간
검색과 지메일, 연락처, 캘린더, 드라이브, 포토, 유튜브 등 우리는 거의 매일 구글의 서비스를 이용하면서 살고 있다고 해도 과언이 아니죠? 구글은 이렇게 다양한 제품에 걸쳐서 관리되고 있는 데이터를 사용자의 허락을 받고 접근할 수 있도록 Google APIs를 제공하고 있는데요. 이번 글에서는 OAuth 2.0을 통해 사용자의 동의를 구하고 구글 API를 호출하는 방법에 대해서 알아보겠습니다. OAuth 2.0이란? 먼저 OAuth 2.0이 생소하신 분을 위해서, 과연 OAuth 2.0가 무엇인지 간단하게 개념부터 짚고 가겠습니다
OAuth 2.0의 인가 코드(Authorization Code) 흐름을 처음 구현해보면, 어딘가 찜찜한 부분이 있습니다. 서버가 있는 웹 애플리케이션이라면 client secret을 안전하게 숨겨둘 수 있는데, 모바일 앱이나 SPA(Single Page Application)는 어디에 숨겨야 할까요? 🤔 APK를 디컴파일하거나 브라우저 개발자 도구를 열면 그대로 노출되니, 사실상 비밀이 아닌 셈입니다. PKCE(Proof Key for Code Exchange, "픽시"라고 읽습니다)는 바로 이 문제를 해결하기 위해 만들어진 보
내 서비스에서 구글 캘린더에 있는 사용자의 일정을 가져와야 한다면 어떻게 해야 할까요? 사용자에게 구글 이메일과 비밀번호를 알려달라고 할 수도 없고, 직접 구글 캘린더에서 일정을 내려받아 달라고 할 수도 없겠죠 😅 OAuth 2.0은 바로 이런 문제를 해결하기 위해 만들어진 프로토콜입니다. 사용자의 비밀번호를 직접 받지 않고도, 사용자가 명시적으로 동의한 범위 내에서 데이터에 접근할 수 있는 표준화된 방법을 제공하는데요. 이번 글에서는 OAuth 2.0의 기본 개념부터 인가 코드(Authorization Code) 흐름까지 차근차
서버 애플리케이션을 개발할 때 사용자 사용자 인증(authentication)과 인가(Authorization)는 데이터 보안을 위해서 매우 핵심적인 기능입니다. 따라서 GraphQL API를 설계하거나, GraphQL 서버를 개발할 때도 사용자 인증/인가 부분에 대해서 여러 가지 고려가 필요합니다. 이번 포스팅에서는 Apllo Server를 이용하여 GraphQL 서버의 사용자 인증과 인가를 구현해보도록 하겠습니다. HTTP 인증 방식 HTTP 인증 방법에는 여러 가지가 있는데, GraphQL 스팩에서는 어떤 특별한 인증 방법을