“사용자 인증을 할 때 쿠키를 사용하면 위험하고요 서버에 데이터를 저장하는 세션을 사용하는 것이 안전해요.” 사용자 인증에 대해서 논할 때 자주 듣게 되는 얘기인데요. 과연 이 말이 맞는 말일까요? 저한테는 굉장히 모순된 얘기로 들리는 것 같습니다. 많은 분들이 쿠키(cookie)와 세션(session)을 서로 대립하거나 세션이 쿠키를 대체하는 기술로 오해하는 것 같은데요. 사실 쿠키와 세션은 상호 보완을 하는 기술이라고 보는 것이 더 맞을 것입니다. 지난 포스팅에서는 서버가 브라우저에 쿠키를 어떻게 저장하고 쿠키라는 기술의 한계에
"쿠키는 클라이언트에 저장되고... 음,,, 보안에 좋지 않습니다." 😅 개발자 면접을 볼 때 쿠키에 대해서 물어보면 가장 흔하게 들을 수 있는 대답인데요. 완전히 틀린 말은 아니지만 뭔가 알맹이가 빠진 느낌이 듭니다. 쿠키가 왜 등장했는지를 이해하려면 HTTP가 무상태(stateless) 프로토콜이라는 점을 먼저 떠올려보면 좋습니다. "그럼 보안을 위해서 쿠키는 안 쓰는 게 좋겠네요?" 라고 반문을 하면 오랫동안 웹 개발을 한 분들도 머뭇거리시는 경우가 많은데요. 아무래도 대부분의 서버 프레임워크에서 쿠키를 직접 다루지 않아도
최근에는 아이디와 비밀번호 입력없이도 구글이나 페이스북과 같은 대형 플랫폼을 통해서 로그인 할 수 있는 서비스들을 많이 볼 수 있습니다. 이번 포스팅에서는 이렇게 사용자 인증을 다른 서비스에 위임하기 위해서 사용되는 프로토콜인 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 인가 흐름까지 차근차근 살펴
쇼핑 사이트에 로그인한 상태로 다른 탭에서 별 생각 없이 열어본 기사 링크 하나가, 내 계정에서 100만 원짜리 상품 주문을 자동으로 날려버릴 수 있다면 믿어지시나요? 바로 이게 CSRF(Cross-Site Request Forgery) 공격의 본질입니다. "사이트 간 요청 위조"라는 이름 그대로, 공격자가 내 브라우저를 통해 내 이름으로 요청을 보내는 공격이에요. 이 글에서는 CSRF가 왜 가능한지, 공격이 실제로 어떻게 성립하는지, 그리고 이를 막는 네 가지 방어 기법(Synchronizer Token, Double Submit
브라우저 개발자 도구에서 Sources 패널을 열어보면 원본 TypeScript 파일이 깔끔하게 표시되곤 합니다. 분명 브라우저가 실행하는 건 번들링되고 압축된 JavaScript일 텐데, 어떻게 원본 코드가 나타나는 걸까요? 바로 소스맵(source map) 덕분이에요. 소스맵은 웹 개발에서 빠질 수 없는 디버깅 도구지만 그 내부를 들여다볼 일은 좀처럼 없는데요. 이 글에서는 소스맵의 JSON 구조와 VLQ 인코딩 원리를 깊이 살펴보고 주요 빌드 도구별 설정 방법도 정리해보겠습니다. 나아가 프로덕션 환경에서 소스맵이 뜻하지 않게
대칭키 암호화는 빠르고 단순합니다. 하지만 한 가지 풀기 어려운 문제를 안고 있는데요. "비밀 키를 어떻게 양쪽이 안전하게 처음부터 나눠 가질 것인가"입니다. 공격자가 통신을 모두 보고 있는 상태에서 비밀 키를 그대로 보낼 수는 없는데, 그렇다고 매번 사람이 직접 만나서 키를 교환할 수도 없는 노릇이죠. 이 닭과 달걀 같은 문제를 풀기 위해 등장한 것이 비대칭키 암호화입니다. 한 사람이 한 쌍의 키를 갖고, 한쪽은 모두에게 공개하고 다른 한쪽은 자기만 가진다는 살짝 마법 같은 발상이에요. 이번 글에서는 비대칭키가 어떻게 동작하는지,
암호화라고 하면 가장 먼저 떠오르는 모습이 자물쇠와 열쇠입니다. 열쇠로 자물쇠를 잠그고, 같은 열쇠로 다시 열고. 이 직관 그대로 동작하는 방식이 바로 대칭키 암호화입니다. 같은 비밀 키 하나로 평문을 암호문으로 바꾸고, 같은 키로 다시 평문으로 되돌리는 약속이죠. 이번 글에서는 대칭키 암호화가 정확히 어떤 약속을 지키는지, AES와 GCM 같은 표준 알고리즘이 어떻게 동작하는지, 그리고 IV나 키 관리 같은 운영 포인트가 무엇인지를 풀어보겠습니다. 대칭키가 지키는 약속 대칭키 암호화는 두 가지 일을 약속합니다. 첫째는 비밀 키를
비밀번호를 다루거나, 파일을 다운로드한 뒤 무결성을 검사하거나, JWT 서명을 살펴볼 때 어김없이 등장하는 친구가 있습니다. 바로 해시 함수입니다. SHA-256이나 bcrypt 같은 이름은 익숙한데, 막상 "해시는 정확히 무엇이고 어디까지 보장하나요"라고 물으면 답이 잘 안 나오는 경우가 많죠. 이번 글에서는 해시 함수가 어떤 약속을 지키는지, 흔히 쓰이는 알고리즘들이 어떻게 다른지, 그리고 실무에서 자주 만나는 쓰임새를 한 번에 정리해 보겠습니다. 해시 함수가 지키는 약속 해시 함수는 임의의 길이를 가진 데이터를 입력으로 받아,
웹 개발을 하다 보면 브라우저 개발자 도구에서 HTTP 요청 헤더를 뜯어볼 일이 종종 있잖아요? 그때 Host, Origin, Referer... 이 세 녀석이 나란히 있는 걸 보면 "이거 다 비슷한 거 아닌가?" 싶을 때가 있는데요. 헤더 자체가 처음이라면 HTTP 메시지가 어떻게 생겼는지부터 보고 오시면 흐름이 더 잘 잡힙니다. 셋 다 URL이나 도메인 정보를 담고 있으니까 대충 같은 역할처럼 보이거든요. 그런데 막상 CORS 문제를 디버깅하거나 보안 설정을 건드려야 할 때 이 헤더들의 차이를 정확히 모르면 삽질을 피할 수가 없
브라우저 주소창에 작은 자물쇠 아이콘이 켜져 있으면 우리는 별다른 의심 없이 정보를 입력합니다. 비밀번호를 치고, 카드 번호를 넣고, 메시지를 보내는데요. 이 자물쇠 한 칸이 사실은 HTTP 위에 한 겹의 보호막을 덧씌운 결과인 셈입니다. HTTPS는 이름에서도 짐작되듯 HTTP에 보안(Secure)을 보탠 형태입니다. 정확히 말하면 HTTP를 TLS라는 암호 통신 위에서 흘려보내는 구조인데요. 이번 글에서는 평문 HTTP가 왜 위험한지, TLS가 그 위에 무엇을 더하는지, 그리고 우리가 평소에 보는 인증서와 자물쇠가 어떻게 신뢰를