MCP 서버를 직접 만들어 보신 적 있으신가요? 처음에는 로컬에서 STDIO로 붙여서 쓰다가, 원격으로 배포하려는 순간 고민이 시작되는데요. "아무나 내 MCP 서버를 호출하면 안 되는데, 누가 접근할 수 있는지 어떻게 가리지?"라는 질문이 떠오르거든요 🤔 이 질문에 대한 공식 답변이 바로 MCP 스펙의 Authorization 섹션입니다. 2025년 11월 25일 개정판에서는 OAuth 2.1을 기반으로 여러 RFC를 조합한 인증 방식을 정리했는데요. 얼핏 보면 OAuth 2.1, RFC 7591, RFC 8414, RFC 87
웹 애플리케이션을 만들 때 인증은 거의 빠지지 않는 기능인데요. 직접 구현하자니 보안 허점이 걱정되고 기존 라이브러리를 쓰자니 특정 프레임워크에 묶이거나 설정이 복잡한 경우가 많습니다. Better Auth는 이런 고민에서 출발한 TypeScript 네이티브 인증 라이브러리입니다. 프레임워크를 가리지 않고 플러그인으로 기능을 확장하고 데이터베이스 스키마까지 직접 관리해 주는 게 특징인데요. 이 글에서는 Better Auth의 설정부터 이메일/비밀번호 인증, 소셜 로그인, 플러그인 활용까지 단계별로 살펴보겠습니다. Better Aut
OAuth 2.0 스펙은 /authorize나 /token 같은 엔드포인트가 존재해야 한다고는 말하지만, 실제로 어떤 경로에 두어야 하는지는 정하지 않습니다. 그래서 한동안 관행은 단순했어요. "구글은 accounts.google.com/o/oauth2/v2/auth, GitHub는 github.com/login/oauth/authorize" 같은 정보를 사람이 공식 문서에서 읽어다가 클라이언트 코드에 박아 넣는 방식이었죠. 이 방식은 금방 한계를 드러냈어요. 새로운 Identity Provider(이하 IdP)를 추가할 때마다 코
OAuth 2.0을 처음 배울 때는 "authorization code를 받아서 access token으로 바꾼다"는 큰 그림만 머리에 담아두어도 충분한데요. 하지만 실제로 연동을 구현하거나 디버깅하는 단계로 넘어가면, 어떤 엔드포인트에 어떤 파라미터를 어떤 조건으로 보내야 하는가가 성패를 좌우합니다. "동의 화면까지는 뜨는데 토큰 교환에서 invalid_grant가 뜬다", "리다이렉트가 자꾸 invalid_redirect_uri로 거부된다" 같은 이슈는 거의 전부 특정 엔드포인트의 파라미터 규약을 놓쳐서 생기거든요. OAuth
JWT access token을 써본 분이라면 이런 순간을 마주쳤을 겁니다. "토큰이 진짜인지는 서명으로 검증한다는데, 그 서명을 확인할 공개 키는 도대체 어디서 얻지?" 또 "Authorization Server가 키를 바꾸면 Resource Server는 그걸 어떻게 따라가지?" 이 두 질문에 한 번에 답하는 장치가 **JWKS(JSON Web Key Set)**입니다. 정확한 출처는 JOSE 스펙인 RFC 7517이고, OAuth는 이 조각을 jwks_uri라는 필드로 빌려다 씁니다. 이 글에서는 JWKS 문서의 구조부터 ki
새 제품을 만들 때 로그인 기능은 거의 예외 없이 등장하는 요구사항인데요. 막상 직접 구현하려고 보면 비밀번호 해싱, 세션, 소셜 로그인 연동, 비밀번호 재설정 메일, 2단계 인증까지 할 일이 끝도 없이 늘어납니다. Auth0는 이 귀찮은 일들을 외주 주듯 맡길 수 있는 관리형 인증 서비스예요. 설정 몇 번에 소셜 로그인과 MFA까지 붙여주기 때문에, 인증 자체가 제품의 핵심이 아니라면 시간을 크게 아낄 수 있습니다. 이 글에서는 Auth0가 어떻게 생긴 서비스인지, 실제로 SPA에 어떻게 붙이는지, 그리고 언제 쓰면 좋고 언제 피
이번 포스팅에서는 Json Web Token, 줄여서 흔히 JWT라고 불리는 사용자 인증/인가 수단 대해서 알아보도록 하겠습니다. JWT 란? JWT(Json Web Token)는 말그대로 웹에서 사용되는 JSON 형식의 토큰에 대한 표준 규격인데요. 주로 사용자의 인증(authentication) 또는 인가(authorization) 정보를 서버와 클라이언트 간에 안전하게 주고 받기 위해서 사용됩니다. JWT 토큰 웹에서 보통 Authorization HTTP 헤더를 Bearer <토큰>의 형태로 설정하여 클라이언트에서 서버로 전
최근에는 아이디와 비밀번호 입력없이도 구글이나 페이스북과 같은 대형 플랫폼을 통해서 로그인 할 수 있는 서비스들을 많이 볼 수 있습니다. 이번 포스팅에서는 이렇게 사용자 인증을 다른 서비스에 위임하기 위해서 사용되는 프로토콜인 OpenID Connect에 대해서 알아보겠습니다. OpenID Connect란? 예전에는 사용자 데이터를 서비스에서 직접 관리하는 경우가 많았지만, 개인 정보가 유출되는 보안 사고가 잇달아 발생함에 따라, 요즘에는 사용자 데이터를 자체적으로 보관하는 것 자체가 부담스러운 작업이 되어가고 있습니다. 이 때문에
검색과 지메일, 연락처, 캘린더, 드라이브, 포토, 유튜브 등 우리는 거의 매일 구글의 서비스를 이용하면서 살고 있다고 해도 과언이 아니죠? 구글은 이렇게 다양한 제품에 걸쳐서 관리되고 있는 데이터를 사용자의 허락을 받고 접근할 수 있도록 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 인가 흐름까지 차근차근 살펴