모의면접 + 피드백 (JWT 토큰)

오늘은 

캠프에서 진행하는 모의면접에 참여했습니다. 

평소 공부했던 내용 + 미리 제공된 예상 질문 덕분에 답변은 잘 했으나 몇 가지 피드백이 있어 오늘의 TIL로 적어둡니다. 

 

1. 말하는 연습이 필요하다. 

- 아는 내용이었지만 답변하는 과정에서 필요 이상으로 길게 설명했던 것 같습니다. 중간중간 뜸을 들이는 시간이나, 부가 설명이 중간에 들어가며 상대로 하여금 이 사람이 제대로 알고 있는 건가 ? 하는 의문을 들 게 할 수 있다는 피드백을 받았습니다.

- 솔루션으로 글로 먼저 내용을 정리해놓고 누군가에게 설명한다는 생각으로, 핵심 키워드 한두 개를 말하는 연습과 부가 설명은 마지막에 필요하다면 덧붙일 것을 권유해 주셨습니다.

 

2. JWT 토큰을 사용하는 이유 + 액세스 토큰 만료에 대하여 

- 첫 번째 질문에서 답변입니다.

Q. JWT(JSON Web Token)을 이용해 인증 기능을 했는데, 만약 Access Token이 노출되었을 경우 발생할 수 있는 문제점은 무엇일까요?
- 기존 사용자가 할 수 있는 웹에서의 역할을 전부 대신할 수 있습니다. 예를 들어 금융 서비스라면 사용자의 금융 데이터가 탈취되는 것과 같으므로 금전적 손실로 이어질 수 있고, 계정에 저장된 좀 더 민감한 개인 정보까지 탈취할 수 있습니다. 사용자의 계정을 바탕으로 다른 유저에게 피싱을 유도하거나 더 큰 피해로 이어질 가능성이 있습니다.

Q. 위의 문제점을 보완하기 위한 방법으로는 어떤 것이 있을까요?
- 토큰이 탈취되는 것을 방지해야 합니다. HTTP 민감한 정보가 포함 통신은 HTTPS를 사용하여 통신을 하고, 탈취되었을 때는 Refresh 토큰을 이용해 기존 토큰을 폐기시키고 재발급하게 하는 방법, 중요한 정보에 접근하게 된다면 2중 인증 방식을 사용해서 액세스 토큰과 또 다른 인증 절차를 통과하게 하여 보안을 강화하는 방법이 있겠습니다.

 

- 해당 답변에서 문제점은 'Refresh 토큰을 이용해 기존 토큰을 폐기시키고 재발급하게 하는 방법' 입니다. JWT 토큰은 서버에 저장되지 않기 때문에 재발급 인증을 위해 저장된 리프레쉬 토큰이 아닌 액세스 토큰은 서버에서 컨트롤할 수 없습니다. 그러므로 폐기 또한 서버에서 관여할 수 없는 부분입니다. 

- 리프레쉬 토큰으로 새로운 액세스 토큰을 재발급 받는다면 기존의 액세스 토큰은 폐기될 것이라는 답변에 튜터님께서 여러 가지 질문을 해주셨고 면접이 마무리된 후 간단히 설명을 해주셨습니다. 

 

JWT, Cookie, Session

이미지 출처 : https://velog.io/@gloom/%EC%BF%A0%ED%82%A4-%EC%99%80-%EC%84%B8%EC%85%98%EA%B7%B8%EB%A6%AC%EA%B3%A0%ED%86%A0%ED%81%B0JWT

 

쿠키와 세션, 그리고 header에 토큰을 포함하여 전송하는 인증 방식에 대해 이해할 필요가 있었습니다. 

 

Cookie를 통한 인증 

- 브라우저에서 행해지는 HTTP 통신에는 Cookie가 자동으로 포함되게 됩니다. Cookie 안에 인증에 필요한 데이터를 담아 서버로 요청을 보내면 서버는 쿠키를 확인하고 인증을 진행합니다.

- 최근 브라우저가 아닌 다른 환경에서는 Cookie를 사용하지 않는다는 문제점이 있습니다. Cookie가 존재하는 브라우저 환경에서만 사용이 가능하고, 여러 도메인에 대한 인증을 추가로 진행해야 될 때는 Cookie 설정에서 해당 도메인들을 추가로 등록해 줘야 합니다.  

 

Session을 통한 인증 

- Cookie는 클라이언트로부터 매번 전달받는 조그마한 데이터 조각입니다. 서버는 쿠키를 Session Storage라는 저장소를 구성하여 저장합니다. 그리고 사용자에게 Session ID를 발급하여 매번 Session ID 값을 조회하고 데이터베이스와 대조하여 인증을 진행합니다. 

- 마찬가지로 Cookie를 사용하기 때문에 Cookie를 사용하는 환경에서만 사용이 가능합니다. 

- 서버에 데이터가 저장되기 때문에 데이터베이스를 서버가 직접 유지시켜야 합니다. 또 매번 조회가 필요하기 때문에 리소스 적으로도 낭비가 될 수 있습니다. 

- 부하 분산을 위하여 여러 개의 서버를 운영하며 있는 다중 서버 환경에서는 세션 인증을 위해 동기화가 필요합니다. 혹은 중앙에 세션 스토리지를 운영해야 하는데 추가적인 비용이 발생할 수 있습니다. 

 

JWT 토큰을 통한 인증 

- JWT 토큰에는 인증에 필요한 정보를 담을 수 있습니다. 서버에서는 추가적인 데이터베이스 구성을 할 필요 없이 토큰을 검증하고 인증을 진행할 수 있게 됩니다. 

- HTTP header에 토큰을 담아서 보낼 수 있으므로 브라우저가 아닌 다른 환경에서도 사용할 수 있는 확장성을 갖고 있습니다. 

- 만약 DB 조회가 필요한 방식으로 MSA와 같은 환경에서 인증을 진행해야 한다면, 서비스가 쪼개져 있으므로 각각의 API 호출이 이뤄질 때마다 DB를 조회해야 합니다. 이는 리소스 낭비로 이어질 수 있는데 JWT 토큰을 사용한다면 리프레쉬 토큰을 재발급 받거나 삭제할 때를 제외한다면 DB를 조회해야 할 필요가 없어지므로 낭비 없이 인증을 진행할 수 있게 됩니다. 

 

그래서 액세스 토큰이 탈취된다면 ?

서버에 저장되지 않기 때문에 서버는 액세스 토큰에 관여할 수 없습니다. 클라이언트가 header에 액세스 토큰을 담아서 보내는 방식은 여러 가지 장점이 있지만, 탈취되었을 때 문제를 야기할 수 있습니다. 그때를 대비하여 리프레쉬 토큰이 존재하며 액세스 토큰의 유효기간을 짧게 설정하여 매번 리프레쉬 토큰을 통해 재발급 받는 방식으로 위험에 대비할 수 있을 것입니다. 마지막으로 리프레쉬 토큰까지 탈취되었다면 어떤 방법으로 대처할 수 있을지 사진을 첨부하며 마치겠습니다. 

Refresh 토큰이 탈취 당한 경우