세션 기반 인증 vs 토큰 기반 인증

세션 기반 인증

- HTTP는 stateless 프로토콜이기 때문에 누가 요청을 했는지, 인증된 client인지를 확인할 수 없음 

=> server 측에 client의 접속 상태를 저장하는 세션 기반 인증 활용

- 요청마다 session storage에 저장된 유효한 세션인지 확인해야 함. 

 

https://blog.lgcns.com/2687

 

 

토큰 기반 인증

- JWT(JSON Web Token)을 가장 많이 사용

- token에 사용자 인증을 위한 정보가 담겨있기 때문에 서버에 사용자 정보를 저장하지 않고, 전달받은 token의 서명과 데이터를 검증하는 것만으로 인증이 가능.

- 사용자의 인증(ID/PW)이 완료되면 서버는 비밀키 또는 공개/개인 키를 이용해 서명한 token을 client에게 전달. 

- client는 토큰을 보관하고 있다가(가장 쉬운 방법은 localstorage에 저장하는 것),

- 데이터 요청할 때마다 client는 token을 포함함.(주로 header에)

- 서버는 token의 서명 값을 이용하여 token이 유효한지 검증하고 유효한 token인 경우 요청에 응답. 

- token 발급 시 token 내 권한 정보를 추가해 권한에 맞는 데이터 응답도 가능.

- 쿠키(웹브라우저에서 사용 가능)를 사용할 수 없는 모바일 어플리케이션에는 JWT를 사용한 인증 방식이 최적.

 

https://blog.lgcns.com/2687

 

---

 

세션 기반 인증 vs 토큰 기반 인증

세션 기반 인증

- 세션 값 자체에는 정보 포함 X

- 상태 정보를 서버 내에 저장

 

 

토큰 기반 인증

- 토큰 값에는 정보 포함. => 일반적으로 더 김. 

- 서버에 클라이언트 상태를 저장하지 않는 무상태성 방식. => 서버 확장에 제약이 적음.

저장 없이 유효한 토큰인지 검증만 필요해서 다른 플랫폼, 서비스 간에 사용하기도 편리.

 

 

---

 

JWT(JSON Web Token)

- 애플리케이션의 액세스 토큰을 만드는데 주로 사용

- 데이터들이 JSON 형태로 작성. 데이터를 비밀키 또는 공개/개인 키로 서명해 사용

- 인가와 정보 교환을 위해 사용 가능. 

- 공개/ 개인 키를 사용해 서명함으로써 송신자 확인 가능, 데이터의 무결성도 확인 가능

 

 

 

JWT 구조

https://blog.lgcns.com/2687

1. 헤더

2. payload : token에 담을 data. data 하나하나를 claim이라고 부름. 

내가 로그인한 유저임을 증명할 수 있는 기본적인 정보들을 넣음. 

차후에 클라이언트가 다시 토큰을 보내면 해독해서 DB내의 유저 정보와 비교.

 

https://blog.lgcns.com/2687

3. 서명(signature)

 

 

 

JWT 사용 시 주의할 점

- 정보노출 : JST의 payload에는 클라이언트와 서버가 사용할 데이터를 저장하는데, 이 데이터는 암호화되지 않고 base64로 encoding 한 값. 이는 누구나 decoding 해서 데이터를 확인할 수 있으므로 payload에는 중요 정보, 민감 정보 등을 포함하지 않아야 함. 

=> payload 내 최소한의 정보(사용자 검증에 필요한 최소한의 식별 및 권한 정보)만을 포함해야 함. 

 

- 알고리즘 타입 중에 'none' : 서명 값 검증을 하지 않음. 

=> none 알고리즘을 포함하는 헤더와 페이로드를 작성해 누구나 토큰을 생성할 수 있고, 악의적으로 사용 가능.

인증과 인가 절차를 우회하여 데이터를 접근할 수 있음. 

=> none 알고리즘을 이용한 서명 없는 토큰은 사용할 수 없도록 조치해야 함. 

 

- 발급된 토큰을 저장하여 검증하는 것이 아니라 토큰의 헤더, 데이터와 서명을 이용하여 검증을 함. 

그래서 key 값을 획득하면, 페이로드의 데이터를 변조해 유효한 토큰을 생성할 수 있고,

이를 통해 인증우회, 권한획득 등의 악의적인 행위 가능.

=> 사용자가 토큰의 비밀키를 획득해 원하는 토큰을 발급하지 못하게 하기 위해서는 안전한 비밀키 사용해 토큰 암호화. (복잡도 높은 비밀키 사용!!)

 

- 토큰 유효기간 및 파기 : 토큰이 탈취되었을 때, 토큰이 만료될 때까지 악의적으로 사용될 위험이 있음. 이 위험을 줄이기 위해 사용자가 토큰을 파기할 수 있는 기능 구현. 

=> Access 토큰과 Refresh 토큰 이용하는 것도 하나의 해결책.

서버에 데이터를 요청할 때는 access 토큰을 이용하며 이 토큰의 유효시간을 짧게 설정.

유효시간이 짧아 토큰이 만료되면 클라이언트는 refresh 토큰을 이용해 서버에 새로운 access 토큰을 요청해 발급받음.

 

 

 

JWT 단점

- JWT는 HTTP를 통해서 전송하기 때문에 페이로드의 크기가 클수록 데이터 전송에 비용이 커짐.

- JWT는 유효기간을 따로 정하지 않는 이상 소멸되지 않기 때문에 장기간 방치 시 해킹의 위험이 커짐.

- JWT를 local storage에 보관한다면 XSS공격에 취약해짐.

(XSS공격 : 외부의 해커가 우리의 프로그램에 특정 javascript 코드를 심어서 localstorage에 접근하는 공격)

=> httpOnly를 설정해서 브라우저만 접근 가능한 쿠키에 토큰을 실어 보내서 XSS공격을 막음.

 

 

 

---

 

Further Topics

• XSS 공격
• 인증과 인가
• 데이터 무결성

 

 

Reference

• https://blog.lgcns.com/2687
• https://devjem.tistory.com/13