[network]토큰기반 인증

인증과 인가

시스템의 자원을 적절하고 유효한 사용자에게 전달하고 공개하는 방법

인증(Authentication)

로그인, 클라이언트가 자기자신아라고 주장하고 있는 사용자가 맞는지를 검증하는 과정이다. 클라이언트가 패스워드를 입력해 제출하면 서버는 유저가 맞는지 확인한다.

인가(Authorization)

인증 작업 이후에 행해지는 작업, 인증된 사용자에 대한 자원에 대한 접근 확인 절차 유저1이 쓴글에 유저2 가 수정 삭제 하지 못하는데이는 인가가 되어 있지 않기 때문이다.

HTTP는 비상태성이라는 특성을 가지고 있어 서버는 클라이언트의 상태를 저장하지 않으며 인증과정을 거쳤는지 알 방법이 없다.

이러한 HTTP 환경에서 서버는 세션 또는 토큰을 사용하여 사용자를 인가한다.

세션기반 인증

사용자의 인증정보가 서버의 세션 저장소에 저장되는 방식

로그인 -> 인증정보 서버의 세션 저장소 저장
Session ID 발급 -> 브라우저 쿠키 형태 저장 -> 실제 인증 정보는 서버에 저장
요청마다 HTTP Cookie 헤더에 Session ID를 함께 서버로 전송
Session ID 해당 하는 세션 정보가 세션 저장소에 존재한다면 해당 사용자를 인증된 사용자로 판단 하여 인가를 수행 해 준다.

장점

서버에 저장하기 때문에 관리가 매우 편하고 효율적
구현이 명확하며 실제 서버에서 로그인 상태를 확인하기 유용
단점
서버에서 클라이언트의 상태를 모두 유지하고 있어야 하므로 클라이언트 수가 많으면 메모리나 DB에 부하가 심하다
멀티 디바이스 환경(모바일, 공동 사용)에서 로그인시 중복 로그인 처리가 되지 않는 등의 신경 써야 할 부분들이 발생한다.
사용자가 많아지는 경우 로드 밸런싱을 사용한 서버 확장을 이용해야 하는데 이때 세션의 관리가 어려워진다.

로드 벨런싱 서버가 처리해야 할 업무 혹은 요청을 여러 대의 서버로 나누어 처리하는것

이러한 단점들로인해 토큰 방식이 생겨남

토큰 기반 인증 방식

인증 정보를 클라리언트가 직접 들고 있는 방식.

유저가 로그인 요청 -> id, pw 정보유효 -> 서버에서 Secret Key를 사용하여 유저에게 토큰 발급
클라이언트 토큰 저장 -> 서버에 요청을 할 때마다 해당 토큰을 함께 서버에 전달
서버는 토큰 검증 -> 요청 응답

토큰 구조

인코딩 암호화된 3가지 데이터를 이어 붙인것

header : 토큰을 어떻게 검증하는가에 대한 내용
playload: 토큰에 담긴 사용자 정보 등의 데이터가 저장 되어있다.
- 누가 누구에게 발급?
- 유효기간
- 사용자에게 이 토튼을 통해 공개하기 원하는 내용 (사용자의 닉네임, 서비스 상의 레벨, 관리자 여부) => 사용자가 받아서 갖고 있는 토큰 자체에 이러한 정보들이 있으므로 서버가 요청마다 데이터베이스에서 찾아야 할 것들이 줄어듬
signature: 부호화 시킨 header와 playload를 가지고 발급해준 서버가 지정한 scret key로 암호화 시켜 토큰 변조하기 어렵게 한다.

장점

클라이언트에 토큰이 저장되어 있기 때문에 서버의 메모리 부담이 되지 않으며 Scale에 있어 대비책을 고려할 필요가 없음
멀티 디바이스 환경에 대한 부담이 없다.
단점
암호화가 풀릴 가능성을 배제 할수 없다.
- 암호화가 풀리더라도 토큰을 사용할수 없도록 만료기간을 짧게 설정한다.(5,6분~ 1시간)
playload 자체는 암호화 되지 않고 base64로 코딩한 데이터이므로, 중간에 playload를 탈퇴하면 디코딩을 통해 데이터를 볼수 있다. 따라서 JWT을 통해 암호화 하거나, playLoad에 중요한 데이터를 넣지 않아야 한다.
JWT 란?

(JSON Web Token)란 인증에 필요한 정보들을 암호화시킨 JSON토큰
JWT 기반 인증 JWT 토큰(Access Token)을 HTTP헤더에 실어 서버가 클라이언트를 식별하는 방식

JWT를 이용한 인증 과정
1. 사용자가 ID, PW를 입력 -> 서버 로그인 인증
2. Header,payLoad,Signature를 각각 Base64로 한 번더 암호화하여 JWT 생성하고 이를 쿠키에 담아 클라이언트에 발급
3. 클라이언트는 서버로 받은 JWT를 로컬스토리 저장(쿠키,세션 저장) API를 서버에 요청할 때 Authorization header에 Access Token 담아 보낸다.
4. 서버는 클라이언트가 Header에 담아 보낸 JWT가 서버내에 발행한 토큰인지 일치여부 확인하여 인증통과 시켜주고 페이로드에 들어있는 유저의 정보들을 select해서 클라이언트에 돌려준다.
5. 클라이언트 -> 서버 요청 했는데 AccessToken 이 만료되면 클라이언트는 refresh token을 이용해서 서버로 부터 새로운 에세스 토큰을 발급 받는다.

쿠키에 JWT 저장 시 취약점

Cross-Site Scripting (XSS) 공격: 쿠키에 저장된 JWT는 XSS 공격에 취약할 수 있습니다. 공격자가 악성 스크립트를 삽입하여 사용자의 브라우저에서 실행되면, 이 스크립트는 쿠키에 접근하여 JWT를 탈취할 수 있습니다.
CSRF (Cross-Site Request Forgery) 공격: CSRF 공격은 사용자가 로그인한 상태에서 공격자가 준비한 트랩 사이트를 방문할 경우, 사용자의 브라우저가 자동으로 쿠키를 포함한 요청을 서버에 보내는 것을 이용합니다. JWT를 쿠키에 저장하면, 이러한 공격에 노출될 수 있습니다.
쿠키 설정의 중요성: 쿠키를 사용할 때 HttpOnly, Secure, SameSite 등의 속성을 올바르게 설정하지 않으면, 보안 취약점이 발생할 수 있습니다. HttpOnly는 XSS 공격으로부터 보호하며, Secure는 HTTPS를 통해서만 쿠키를 전송하도록 합니다. SameSite 속성은 쿠키가 동일한 사이트에서만 전송되도록 제한합니다.

해결책

로컬 스토리지 사용: 쿠키 대신 JWT를 로컬 스토리지에 저장하는 방법이 있습니다. 하지만 이 방법 역시 XSS 공격에 취약할 수 있습니다.
쿠키의 보안 속성 설정: 쿠키에 JWT를 저장할 때는 보안 속성을 적절히 설정하는 것이 중요합니다.
토큰의 만료 시간 단축: 토큰 탈취 위험을 줄이기 위해 토큰의 유효 시간을 짧게 설정합니다. 이러한 점들을 고려하여 시스템을 설계하고 구현하는 것이 중요합니다. JWT와 쿠키를 사용할 때는 항상 보안 측면을 고려하여 적절한 방어 메커니즘을 구현해야 합니다.

Hah-nna / Tech_Interview

[network]토큰기반 인증 #26