[SW사관학교 정글] WEEK00_Project_로그인 방식

[SW사관학교 정글] WEEK00_Project_로그인 방식

 

로그인을 위한 기술은 세션, 쿠키, JWT를 위한 방법이 있다.

 

기본적으로 HTTP(HyperText Transfer Protocol) 통신의 특징은 접속 후 접속을 끊는 Connectionless(비 연결)와 상태정보를 보관하지 않는 Stateless(비 상태유지)이다. 그러므로 HTTP 요청시 이전 요청에 대한 정보와 무관하다. 그래서 로그인 기능을 사용하기 위해서는 요청 주체에 대한 '인증'이 필요하다. 이 인증을 통해 사용자  A와 B에 대하여 서버에서 클라이언트에 다른 화면을 보낸다.

 

1. 계정 정보를 요청 헤더에 넣는 방식

장점 : 빠르게 인증 테스트 시도 가능

단점 : 계정 정보에 대한 접근이 매우 쉬워 보안 매우 취약.

 

2. Session / Cookie 방식

Session ID를 쿠키로 저장하기 때문에 Session ID = 쿠키 라고 생각해도 무방하다.

세션은 서버가 가지고 있는 정보, 쿠키는 사용자에게 발급된 세션을 열기 위한 열쇠(Session ID)를 의미한다.

쿠키만으로 인증한다는 것은 서버의 자원은 사용하지 않는다는 것이며, 인증 정보에 대한 책임을 클라이언트가 진다는 것을 의미한다. 서버의 보안이 클라이언트 보다 대체로 안전하기 때문에 세션을 이용해 서버에 인증 책임을 지우게 된다.

 

장점 :

1) 쿠키(Session ID)를 이용해 인증을 거치기 때문에 이 쿠키 자체는 유의미한 값을 가지고 있지 않다.

2) 클라이언트가 고유의 ID를 발급받게 되어 쿠키 값을 받았을 때 일일이 회원 정보를 확인할 필요가 없다.

단점 :

1) 쿠키를 탈취당했을 경우 그 쿠키로 로그인이 가능하다. -> 쿠키의 정보를 읽기 힘들게 만들거나 유효시간을 넣어 보완할 수 있다.

2) 세션 저장소를 이용하므로 저장공간이 필요하고 부하도 높아진다.

 

3. 토큰 기반 인증 방식 JWT(Jason Web Token)

토큰을 만들기 위해서는 3가지 Header, Payload, Verify Signature가 필요하다.

Header : 위 3가지 정보를 암호화할 방식(alg), 타입(type) 등이 들어간다.

payload : 서버에서 보낼 데이터가 들어간다. 일반적으로 유저의 고유 ID값, 유효기간이 들어간다.

Verify Signature : Base64 방식으로 인코딩한 Header,payload 그리고 SECRET KEY를 더한 후 서명된다.

Verify Signature는 SECRET KEY를 알지 못하면 복호화할 수 없다.

장점 : 

1) 추가 저장소가 필요없어 간단하다. 서버 확장이나 유지, 보수에 유리하다

2 확장성이 뛰어나다. 토근 기반의 다른 인증 시스템에 접근이 가능하다.

 

단점 :

1) 이미 발급된 JWT에 대해서는 없애지 못한다. 즉 유효기간 동안 계속 악의적으로 사용할 수 있다.

2) 누구나 확인할 수 있어 Payload 정보가 제한적이다.

3) JWT의 길이가 세션/쿠키 방식에 비해 길다.

 

참조 by https://tansfil.tistory.com/58