Session, JWT, OAuth

(20250812 cs정리 대신)

인증과 인가

• 인증(Authentication): ‘너는 누구인가?’를 확인하는 과정입니다. 사용자가 ‘자신이 누구인지 증명하는 것’ 입니다.
  • 비유: 회사의 출입문에 달린 지문 인식기나 카드 리더기에 본인의 지문을 찍거나 사원증을 태그하는 행위. 시스템은 ‘이 사람이 A 회사의 직원 김아무개가 맞다’는 것을 확인합니다.
  • 예시: 아이디와 비밀번호를 입력해 로그인하는 과정
  • ErrorCode : 401
• 인가(Authorization): ‘너는 무엇을 할 수 있는가?’를 확인하는 과정입니다. 사용자가 ‘어떤 특정 자원에 접근할 수 있는 권한이 있는지’를 검증하는 것입니다.
  • 비유: 출입문 통과 후, 김아무개 사원이 자신의 팀 사무실에는 들어갈 수 있지만, 재무팀 사무실에는 들어갈 수 없도록 제한하는 것. 시스템은 ‘김아무개는 개발팀 사무실에 접근할 권한이 있다’는 것을 확인합니다.
  • 예시: 로그인한 사용자에게만 특정 페이지나 기능을 보여주는 것. 관리자 권한을 가진 사용자에게만 회원 정보 수정 기능을 제공하는 것
  • ErrorCode : 403

인증이 먼저 이루어져야 인가를 할 수 있습니다. 시스템이 먼저 사용자가 누구인지(인증) 확인한 후에, 그 사용자가 어떤 권한을 가지고 있는지(인가)를 판단하게 됩니다.

세션 기반 인증

서버가 사용자의 상태를 기억하는 Stateful한 방식입니다.

동작방식

• 클라이언트가 로그인 요청을 합니다.
• 서버는 사용자의 정보를 검증하고 서버 메모리나 데이터베이스에 고유한 세션 ID를 생성해 저장합니다.
• 서버는 생성된 세션 ID를 클라이언트에게 응답으로 보냅니다.
• 클라이언트는 이 세션 ID를 쿠키에 저장합니다.
• 이후 클라이언트는 매 요청마다 쿠키에 담긴 세션 ID를 서버로 보냅니다.
• 서버는 전달받은 세션 ID를 통해 세션 저장소에서 사용자 정보를 찾아 요청을 처리합니다.

장점

• 보안성: 세션 ID만으로 사용자 정보를 알 수 없으며, 서버에서 세션 파기 시 강제로 로그아웃시킬 수 있어 안전합니다.
• 간편한 관리: 서버에서 세션의 만료 시간을 설정하고 관리하기 용이합니다.

단점

• 서버 부하: 사용자 수가 많아질수록 서버의 메모리나 DB에 저장해야 할 세션 정보가 늘어나 서버에 부하가 발생합니다.
• 확장성 문제: 서버를 여러 대로 확장할 때 세션 정보를 모든 서버가 공유해야 하는 문제가 발생합니다. 이를 해결하기 위해 Redis같은 별도의 세션 저장소를 사용해야 합니다.

JWT 기반 인증

서버가 사용자의 상태를 기억하지 않는 Stateless한 방식입니다.

동작 방식

• 클라이언트가 로그인 요청을 합니다.
• 서버는 사용자의 정보를 검증한 후, 사용자의 정보를 담은 JWT를 생성합니다.
• 서버는 생성된 JWT를 클라이언트에게 응답으로 보냅니다.
• 클라이언트는 JWT를 로컬 스토리지나 쿠키에 저장합니다.
• 이후 클라이언트는 매 요청마다 Authorization헤더에 JWT를 담아 서버로 보냅니다.
• 서버는 토큰의 서명을 검증하여 유효성을 확인하고, 토큰 내의 정보를 사용해 요청을 처리합니다.

장점

• 확장성: 서버가 상태를 저장하지 않으므로 여러 서버로 확장하기 용이합니다.
• CORS 문제 해결: JWT는 헤더에 포함되어 전달되므로 CORS 문제에 유연하게 대처할 수 있습니다.

단점

• 보안성: 토큰이 탈취될 경우, 토큰의 유효 기간이 끝날 때까지 악용될 수 있습니다. 이를 보완하기 위해 Refresh Token을 사용하기도 합니다.
• 토큰의 크기: 페이로드에 많은 정보를 담을수록 토큰의 크기가 커져 네트워크 부하가 증가할 수 있습니다.

OAuth

직접적인 비밀번호 공유 없이 제3자 애플리케이션에 사용자의 권한을 위임하는 인가 프로토콜입니다.

동작방식

• 클라이언트는 리소스 서버(ex. 구글)에 로그인을 요청하는 대신, 인가 서버에 인가 코드를 요청합니다.
• 인가 서버는 사용자에게 “이 애플리케이션이 당신의 정보를 사용해도 될까요?”라고 동의를 구합니다.
• 사용자가 동의하면 인가 서버는 클라이언트에게 인가 코드를 발급합니다.
• 클라이언트는 인가 코드를 인가 서버로 다시 보내 접근 토큰을 발급받습니다.
• 클라이언트는 이 접근 토큰을 이용해 리소스 서버에 접근하여 사용자 정보(이름, 프로필 사진 등)를 가져옵니다.

장점

• 보안성: 사용자가 서비스 제공자에게 직접 비밀번호를 알려주지 않아도 되므로, 개인정보 유출 위험을 크게 줄일 수 있습니다.
• 편의성: 사용자는 아이디와 비밀번호를 여러 곳에 기억할 필요 없이 소셜 로그인 등으로 간편하게 서비스를 이용할 수 있습니다.

단점

• 복잡한 흐름: 세션이나 JWT에 비해 동작 흐름이 복잡하고, 여러 주체가 등장합니다.
• 목적의 차이: OAuth는 인증이 아닌 인가를 위한 프로토콜이라는 점을 이해해야 합니다. OAuth를 통해 발급받은 토큰으로 사용자 정보를 가져와서 로그인을 구현하는 것이 일반적입니다.

기타

• SSO (Single Sign-On)
  • 한 번의 로그인으로 여러 개의 다른 애플리케이션이나 서비스에 접속할 수 있게 해주는 인증 방식입니다. 여러 개의 시스템을 운영하는 회사에서 직원들이 각 시스템마다 따로 로그인하는 불편함을 해소하기 위해 주로 사용됩니다.
  • ex. 구글 워크스페이스
• HTTP Basic Authentication
  • 클라이언트가 요청을 보낼 때, Authorization 헤더에 Basic 타입과 함께 아이디 : 비밀번호를 Base64로 인코딩한 값을 담아 보냅니다.
  • 보안에 매우 취약합니다. 암호화되지 않은 평문 데이터를 Base64로 인코딩만 한 것이라, 중간에 탈취될 경우 바로 노출됩니다. 따라서 HTTPS 환경이 아닌 곳에서는 절대 사용해서 안 됩니다.