오늘은 백엔드 개발자라면 반드시 마주치게 되는 **인증(Authentication)**과 인가(Authorization) 구현에 대해 이야기해볼게. 많은 신입 개발자들이 이 둘의 개념을 혼동하거나, 단순히 라이브러리가 제공하는 기능을 복사-붙여넣기 하다가 보안 사고를 내곤 하거든. 내가 12년 동안 백엔드 필드에서 구르면서 겪었던 경험을 바탕으로, 실무에서 꼭 알아야 할 핵심만 짚어줄게.
1. 인증과 인가의 개념을 명확히 구분하자
먼저 이 둘을 헷갈리면 설계부터 꼬이게 돼. 인증은 '이 사용자가 진짜 우리 서비스의 회원이 맞는지 확인하는 과정'이고, 인가는 '인증된 사용자가 특정 API나 리소스에 접근할 권한이 있는지 검증하는 과정'이야.
- 인증(Authentication): 로그인 (ID/PW 확인, 생체 인증 등)
- 인가(Authorization): 글쓰기 권한이 있는지, 관리자 페이지에 들어갈 수 있는지 체크 실무에서는 보통 인증을 통과한 사용자에게 세션이나 토큰을 발급하고, 이후 요청부터는 이 토큰을 검증해서 인가 처리를 하게 돼. 이 흐름을 머릿속에 꼭 넣어두고 개발을 시작해야 해.
2. JWT를 쓸 때 가장 흔히 하는 치명적인 실수
요즘은 Stateless한 아키텍처를 위해 JWT(JSON Web Token)를 정말 많이 쓰잖아. 그런데 많은 후배들이 JWT의 페이로드(Payload)가 암호화되어 있다고 착각하더라. 페이로드는 단순히 Base64로 인코딩된 것뿐이라, 누구나 디코딩해서 안의 내용을 볼 수 있어.
따라서 페이로드에는 절대로 비밀번호나 주민번호 같은 민감한 정보를 넣으면 안 돼. 오직 사용자를 식별할 수 있는 최소한의 정보(예: userId)만 넣어야 하지. 그리고 토큰 탈취에 대비해서 Access Token의 유효기간은 30분 내외로 짧게 잡고, 이를 재발급하기 위한 Refresh Token을 안전하게 관리해야 해. 이때 Refresh Token Rotation(RTR) 기법을 도입하면 보안성을 훨씬 높일 수 있어.
3. OAuth 2.0은 로그인 도구가 아니다
구글이나 카카오 로그인 기능을 구현할 때 OAuth 2.0 프레임워크를 많이 쓰지? 그런데 많은 이들이 오해하는 게 있어. OAuth는 본질적으로 '인증'이 아니라 '인가(권한 부여)'를 위한 프로토콜이야. 우리 서비스가 구글을 대신해서 로그인하는 게 아니라, 구글이 가진 사용자 정보(리소스)를 우리 서비스가 안전하게 접근할 수 있도록 권한을 위임받는 흐름이거든.
만약 순수한 '인증' 목적으로 소셜 로그인을 구현하고 싶다면, OAuth 2.0 위에 얹어진 OIDC(OpenID Connect) 스펙을 사용하는 것이 표준에 더 맞아. 실무에서 아키텍처를 설계할 때 이 차이를 알고 토큰 스펙을 결정하는 개발자는 완전히 다르게 보이거든.
💡 핵심 정리
- 인증은 신원 확인, 인가는 권한 검증이다.
- JWT 페이로드는 암호화되지 않으므로 민감한 정보를 절대 담지 마라.
- OAuth 2.0은 권한 위임(인가) 프레임워크이며, 인증은 OIDC를 활용하는 것이 좋다. 라이브러리가 알아서 해준다고 코드만 복사하지 말고, 토큰이 탈취되었을 때의 시나리오를 직접 그려보며 방어 로직을 짜봐. 보안은 '설마'하는 순간 뚫리는 법이니까, 한 번 더 의심하고 검증하는 습관을 들이길 바랄게.