2023 - 07 - 07 Json Web Token (JWT)의 장단점, 토큰과 DB 사용자 인증, 쿠키, 세션 (면접 단골질문)

 

 

jwt > 면접 단골질문

질문 : 왜 db에서 검색하는데 토큰에서 한번 더 검색하는가??

jwt로 사용자인증 미들웨어 구현이 가능하다.
jwt 장점: 암호화/보안/검증된 라이브러리.
> 따로 저장하지 않아도 된다.
> 쿠키안에 키랑 정보가 다 들어있어서 저장공간이 별도로 필요 없다.
> 인증에 대한 정보가 담겨 있다.
> DB에 저장한 데이터를 보지 않아도 이 토큰이 암호화/복호화를 통해 위변조 되었는지를 알 수 있다. 

위변조를 토큰만 보고도 검증할 수 있다.
그런데 왜 토큰만 보고 알 수 있는데, 유저아이디로 DB를 한번 더 검증해서 가져올까?
> 토큰이 만료되기 전에 유저 DB의 정보가 변경되었을 경우 한번 더 비교하기 위해서?
>>> 사실은 필요없다. (이 로직에서는)

>>> 유저아이디로 DB를 한번 더 검증하는 것이 필요할 때가 언제인가?
> 유저 정보의 모든 정보가 필요한 로직이 있다고 가정하고, 유저 정보를 조회하기 위해 필요하다.

ex)닉네임을 조회하기 위해 db를 조회했다.
>> 닉네임이 보여져도 상관없다면 해당 닉네임을 jwt에 포함시킨다.

ex)작성자의 연락처가 필요하다.
>> 전화번호는 보여지면 안되는 정보이기 때문에 해당 상황에서 조회한다.

경우에 따라서 넣어야 될 필요는 있지만, 넣지 않는 편이 좋다.
우리 팀의 로직에서는 DB조회 부분이 필요가 없는 경우.

유저아이디로 DB를 한번 더 검증하는 것이 필요한 경우
서비스에 어드민이 있다. 
악질 사용자가 있을 떄 사용 금지 시키고 싶음
ex) 활동정지, 임시차단 

jwt로만 인증하면 이 유저를 악성 사용자인지 알 수가 없다. 
근데 db로는 악성 사용자인지 구분을 할 수 있기 때문에 이런 상황에서는 필요하다.

ex)
jwt로 검증은 가능하다. 그러나 jwt 안에있는 정보만으로는 권한을 주는것을 판단하기 어려운 상황일 때
db조회로 권한 설정 여부를 판단해야 한다.

 

인증 (Authentication)

• 로그인
• 놀이공원 입장

인가 (Authorization)

• 사용자의 로그인 이후의 활동에 대한 서버의 허가
• 티켓을 보여주면 놀이기구를 탈 수 있음

인증과 인가의 방법

쿠키, 세션, 토큰

JWT(Json Web Token)

• 서비스에서 유저를 인증하고 식별하기 위한 Token(토큰) 기반 인증 방식
• 토큰은 세션과 달리 서버가 아닌 클라이언트에 저장된다.
• 인증에 필요한 정보들을 암호화시킨 Json형식의 토큰

JWT의 구조 & 생성 & 발급

• Header(헤더)
  JWT에서 사용할 타입과 해시 알고리즘의 종류

{
  "alg": "HS256",
  "typ": "JWT"
}

• payload(페이로드)
  서버에서 첨부한 사용자 권한 정보와 사용자의 데이터
  "...": "..."의 key-value의 한 쌍을 Claim이라고 한다.

{
  "sub": "1234567890", 
  "name": "John Doe",
  "admin": true
}

• Signature(서명)
  - Header, Payload 를 Encode를 한 이후 Header 에 명시된 해시함수를 적용하고, 개인키(Private Key)로 서명한 전자서명
  - (헤더 + 페이로드)와 서버가 갖고 있는 유일한 key 값을 합친 것을 헤더에서 정의한 알고리즘으로 암호화를 한다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

위의 헤더, 페이로드, 서명 등의 정보를 인코딩(Base64 URL-safe Encode)해 아래와 같은 형태로 클라이언트에게 발급한다.

JWT 인코딩 / 디코딩

• jwt.io

JWT 인증 과정

출처 : Dev Scroll

1. 클라이언트가 id, pw와 함께 서버에 로그인을 요청한다.
2. 서버가 요청을 받고, Header, Payload, Signature를 정의하고 Base64로 인코딩(암호화)하여 JWT를 생성해 쿠키에 담아 클라이언트에게 발급한다.
3. 클라이언트는 JWT를 로컬 저장소에 저장하고, 서버에 요청을 보낼 때 Authorization header에 Access Token을 담아서 보낸다.
4. 서버는 클라이언트가 Header에 담아 보낸 JWT가 서버에서 발급한 토큰인지 일치 여부를 확인해 인증을 통과 혹은 거부를 한다.
5~6. 클라이언트의 Access Token의 시간이 만료되면 Refresh Token을 사용해 새로운 Access Token을 발급받는다.

서버는 JWT를 이용해 토큰의 정보를 아는 게 중요한 것이 아니라 클라이언트가 요청과 함께 보낸 JWT가 유효한 토큰인지 검사하는 것이 중요하다.
클라이언트가 보낸 JWT의 Header, Payload를 서버의 key값을 이용해 Signature를 만들어 클라이언트가 보낸 Signature와 일치하는지 확인하고 일치하면 인증을 통과시킨다.(인가)

토큰의 진짜 목적은 정보 보호보다는 위조 방지이다.

JWT 장점

• 데이터의 위변조를 방지한다.
• JWT는 인증에 필요한 모든 정보를 담고 있기 때문에 인증을 위한 별도의 저장소가 없어도 된다.
• 세션(Stateful)과 다르게 서버는 무상태(StateLess)가 된다.
• 확장성이 우수하다.
• 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.(쿠키와의 차이)
• OAuth의 경우 소셜 계정을 통해서 다른 웹서비스에 로그인 할 수 있다.
• 모바일에서도 잘 동작한다.(세션은 모바일x)

Tip
서버에서 가장 피해야 할 것은 DB 조회이다.
서버가 죽는 경우 중 대부분은 DB가 터져서 서버도 같이 죽는 경우이다.
이와 관련해서 JWT는 DB조회가 필요없다는 장점을 가지고 있다.

JWT 단점

• 쿠키/세션과 다르게 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
• Payload 자체는 암호화가 되지 않아 중요한 정보는 담을 수 없다.
• 토큰을 탈취당한다면 대처가 매우 어렵다.

JWT vs Cookie & Session

장점단점

Cookie & Session	1. Cookie만 사용하는 방식보다 보안 향상 2. 서버 쪽에서 Session 통제 가능3. 네트워크의 부하가 낮음	세션 저장소 사용으로 인한 서버의 부하
JWT	1. 인증을 위한 별도의 저장소가 필요 없다. 2. 빠른 인증 처리 3. 확장성 우수	토큰의 길이가 길수록 네트워크의 부하가 증가, 특정 토큰을 강제로 만료시키기가 어렵다.