HTTPS와 SSL/TLS

HTTPS는 HTTP + SSL/TLS 계층. 통신을 암호화하는 프로토콜.최신 TLS1.3의 경우 설명하며
SSL/TLS는 보안 세션을 기반으로 통신을 암호화하며 보안 세션이 만들어질 때 인증 메커니즘, 키
교환 암호화 알고리즘, 해싱 알고리즘이 사용됩니다.

 

 

로그인방식: 쿠키와 세션 그리고 토큰방식(JWT)

 

HTTP의 특징 중 하나는 stateless 합니다. 즉, 연결을 끊는 순간, 사용자와 서버의 통신이 끝이 나며
상태 정보는 유지하지 않는 특성이 있습니다. 즉, 로그인같은 것을 그냥 둬서는 구현을 하지 못하죠.
그래서 이 “상태”를 유지하는 방법으로는 2가지 방법이 있습니다.
- 쿠키와 세션
- 토큰기반 방식

 

쿠키와 세션 방식
세션
- 서버와 클라이언트의 연결이 활성화된 상태.
세션ID
- 웹 서버메모리에 저장되는 클라이언트에 대한 유니크한 ID (서버 또는 데이터베이스에 저장)
쿠키
- 키 – 값으로 구성된 작은 데이터 조각
- 쿠키에 담긴 데이터는 브라우저에서 관리됨.(but, 보통 만료날짜를 서버에서 설정함)
- 이름, 값, 만료 날짜 등으로 구성

 

쿠키와 세션 프로세스
1. 처음 로그인 > 쿠키, 세션ID 생성 , 그 이후 다시 요청했을 때 HTTP 헤더에 쿠키를 포함시켜
요청한다.
2. 해당 쿠키에 맞는 세션ID로 전에 로그인했던 아이디인지 확인
3. 로그인을 유지

 

쿠키
쿠키는 클라이언트에서 자바스크립트로 조회가 가능 , 공격자들이 자바스크립트로 쿠키를
가로채고자 시도를 할 수 있습니다. 이를 XSS라고함(Cross Site Scripting)
해결방법 : HTTP Only Cookie 또는 secure cookie를 사용하며 다음과 같이 셋팅을 하면 됩니다.
- Set-Cookie: 쿠키명=쿠키값; path=/; HttpOnly
- Set-Cookie: 쿠키명=쿠키값; path=/; secure

 

쿠키 - 세션의 단점
로그인 중인 유저의 수가 늘어난다면 서버의 메모리 과부화 등 악영향을 줍니다. 로그인할 때마다
세션ID를 저장해야 하기 때문이죠.

 

토큰기반인증 방식
토큰기반인증방식은 인증은 토큰기반 인증서버를 통해 하고 다른 서버는 stateless하게
내버려두자는 이론이 담겨있는 인증방식입니다.

 

1. 요청 > 토큰생성
2. 이후 사용자가 토큰을 헤더(authorization) 키에 넣어서 요청,
토큰은 주로 JWT토큰이 활용됨.

 

JWT(JSON Web Token, RFC 7519)
헤더, 페이로드, 서명으로 이루어져 있으며 JSON 객체로 인코딩되며 메시지 인증, 암호화에
사용됩니다.

 

Header
- 어떠한 방법의 서명 알고리즘을 사용할 것인가에 대한 정보.

 

Payload
- 데이터, 토큰 발급자, 토큰 유효기간(인증이 필요한 최소한의 정보만)

 

Signature
- 헤더에 정의된 알고리즘으로 인코딩된 헤더와 페이로드를 합친값, 그리고 비밀키를 기반으로
생성된 서명값

 

JWT 토큰기반인증 방식의 장점
사용자가 인증되면 사용자는 모든 시스템에서 사용할 수 있는 보안 토큰을 받습니다. 즉, 단일
엔드포인트를 생성해서 다른 모든 서버간의 API 상호작용을 인증할 수 있다는 점에서 좋으며 사용자
인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요 없습니다 반면
세션의 경우 계속해서 저장해야 합니다. 확장성, 디버깅 측면에서 좋으며 사이즈가 작습니다. 또한
JWT토큰 자체가 독립적입니다.

 

JWT 토큰기반인증 방식의 단점
더 많은 필드가 추가되면 토큰이 비대해져 트래픽에 영향이 있고 탈취하여 디코딩하면 데이터를 볼 수
있음