Client 인증 방식 (Cookie, Session, JWT)

Cookie 인증

- 쿠키(Cookie) = 서버에서 클라이언트에 저장하는 문자열 데이터

인증 과정 

1. 클라이언트가 서버에 요청 전송

2. 요청을 받은 서버가 클라이언트에 저장하고 싶은 데이터를 Response Header의 Set-Cookie에 담아 전송

3. 클라이언트는 전송받았던 쿠키를 서버에 Request Header를 전송할 때마다 Request Header의 Cookie에 담아 전송

4. 서버는 Requset Header에 담긴 Cookie에 대한 정보를 참조하여 인증 수행

특징

- [key1=value1; key2=value2; ...] 형식

- 편의성&재사용성 제공 => ex) 로그인 여러 번 할 필요 X

- 보안성 취약 

- 브라우저 간 공유 불가능

- 용량 제한 (도메인 당 20개, 한 쿠키 당 4KB)

 

Session 인증

- 세션(Session) = 브라우저가 종료되기 전까지 클라이언트의 요청을 유지하게 해주는 기술

인증 과정 

1. 클라이언트가 서버에 로그인 요청 전송

2. 요청을 받은 서버가 id/pw 체크 후 중복 없는 고유한 Session ID를 생성하여 서버의 세션 저장소에 저장

3. 서버가 Session ID를 Response Header의 Set-Cookie에 담아 클라이언트에 전송 

4. 클라이언트는 전송받았던 Session ID를 서버에 전송할 때마다 Request Header의 Cookie에 담아 전송

5. 서버는 전송받은 Session ID를 세션 저장소에 저장된 Session ID들과 비교하여 인증 수행 

특징

- [key(세션 ID) : value] 형식이며 value도 Map 형식(key:value)로 구성

- 쿠키보다 보안성이 좋고 용량 제한 X

- 각 클라이언트 마다 고유한 세션 ID를 부여함 (unique)

- 일종의 서버에 저장되는 쿠키

 

JWT

- JWT(JSON Web Token) = 인증에 필요한 정보들을 암호화시킨 JSON 토큰 

- RFC 7519

- JSON 데이터를 Base64를 통해 인코딩하여 직렬화한 것

구조

- [헤더(Header).내용(Payload).서명(Signature)] 형태로 구성

- 헤더(Header) = 토큰 타입과 알고리즘 종류

- 내용(Payload) = 시스템에서 실제로 사용될 정보에 대한 내용(JWT ID, 유효시간, 사용자 이름 등)

=> Payload에는 중요한 정보 넣지 말아야 함

※ 클레임(Claim) = Payload에서 key:value 형식으로 저장되어 있는 데이터 (3종류 => 등록, 공개, 비공개)

- 서명(Signature) = 헤더의 인코딩 값 + 내용의 인코딩 값 + 비밀키를 헤더에서 정의한 알고리즘으로 해싱한 값 

 

JWT 인증

일반적인 토큰 인증 과정 

1. 클라이언트가 서버에 로그인 요청 전송

2. 요청을 받은 서버가 id/pw 체크 후 중복 없는 고유한 토큰을 생성하여 클라이언트에 전달 (저장 X)

3. 클라이언트는 받은 토큰을 저장한 뒤 다시 서버에 요청을 보낼 때 Request Header에 토큰을 담아 전송

4. 서버는 클라이언트로부터 전송받은 토큰이 서버가 보냈던 토큰과 일치하는지 비교하여 인증 진행

Access Token & Refresh Token

- Access Token = 실제 정보가 담긴 토큰으로 인증에 사용
- Refresh Token = 새로운 Access Token 발급에 사용
- Access Token은 유효기간을 짧게, Refresh Token은 유효기간을 길게 설정
- DB에 Access Token과 Refresh Token을 쌍으로 저장하고 클라이언트에 Access Token과 Refresh Token을 모두 요구해야 보안이 좋음

JWT 토큰 인증 과정

1. 클라이언트가 서버에 로그인 요청 전송

2. 서버가 JWT(Access 토큰, Refresh 토큰)를 생성 후 Response Header의 Set-Cookie에 담아 클라이언트에 전송

3. 클라이언트는 받은 토큰을 저장한 뒤 API를 서버에 요청할때 Authorization header에 Access 토큰을 담아 전송

4. 서버는 클라이언트로부터 전송받은 토큰이 서버가 보냈던 토큰과 일치하는지 비교하여 인증 진행

(만약 유효시간이 다 됐을 경우 클라이언트에서 Refresh 토큰을 재전송하여 새로운 Acess 토큰 재발급)

특징

- 데이터 위변조 방지

- 인증 정보에 대한 별도 저장소 필요 X

- 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유 가능

- 웹과는 다르게 앱에는 세션과 쿠키가 없어 많이 사용되는 인증 방식

- 토큰이 서버가 아닌 클라이언트에 저장되기 때문에 서버에 부담이 적어짐

- 세션과 다르게 브라우저가 종료되지 않고 유지될 필요 X (Stateless) 

- 토큰을 탈취당하면 Payload를 모두 볼 수 있어 대처하기가 힘듦

- 쿠키와 세션에 비하여 데이터의 길이가 매우 김

JWT 인코딩/디코딩 사이트

https://jwt.io/

JWT.IO