궁금증 집합소

두별·2022년 5월 2일

TIL

목록 보기

20/46

업무를 위해 플로우 차트를 그리다가 궁금한 것들에 대해서 조사를 해보았다.
내가 개발해야하기 때문에 왜 이렇게 해야 하는지 이유를 정의하고자 찾아본 조사결과이고, 무조건 정답은 아님.

1. 사용자 정보 암호화

Password 암호화

사용자 등록 혹은 로그인시 DB에 저장된 Password와 비교하기 위한 용도

로그인시 Password는 스프링 security의 BCrypt 클래스를 이용해서 해싱 암호화를 하는데,
해싱함수로 암호화된 평문은 복호화를 할 수 없다.

BCryptPasswordEncoder란?
Spring Security에서 지원하는 비밀번호 암호화 클래스
비밀번호를 해싱함수로 암호화,
hash값에 salt값을 결합하여 무결성 보장

사용자 정보 암호화

Password는 DB에 저장된 값과 비교만 하면 되기 때문에 BCrypt를 쓰지만 사용자 정보는 암호화해서 꺼내쓸때마다 복호화를 해야하기 때문에 Java에 내장된 보안 알고리즘을 사용하여 암호화 할 것이다.
예를 들어 대칭키 알고리즘에는 AES, DES가 있고 비대칭키 알고리즘에는 RSA가 있는데,
비대칭 알고리즘은 속도가 느리기 때문에 높은 안정성과 속도가 장점인 대칭키 알고리즘 AES256을 사용하는 것이 좋다.

Password는 스프링 Security의 BCrypt 클래스로 암호화, JWT 토큰안에 넣는 사용자 정보는 Java의 대칭키 알고리즘 AES256을 사용하여 암복화 한다.

2. Access Token은 뭐고 Refresh Token은 뭐야?

Access Token

암호화된 사용자 정보, 발급일시, 만료일시

Refresh Token

Access Token이 만료되었을때 새로 생성해주기 위한 용도의 Token
발급일시, 만료일시 정도의 정보만 있음

보통 Access Token보다 만료일시를 길게 해주므로 민감한 정보는 Access Token에 암호화해서 담고 Refresh Token에는 담지 않는다. Refresh Token은 있냐 없냐의 여부만 중요한 편

3. JWT를 Vue Store, Local Storage에 저장해야하는 이유

Vue Store

JWT 안에는 사용자 정보가 암호화되어서 저장되어 있기 때문에 프론트 단에서 꺼내쓸 수 가 없다. 따라서 최초 로그인 성공시 암호화되어있지 않은 사용자 정보를 Vue store에 저장해주어야 한다. (단 민감한 정보를 제외한 화면에 뿌려지기 위한 용도의 데이터)

프론트단에서 사용자 정보를 꺼내쓰기 위해서, api요청시 token을 넘겨주기 위해서 Vue store에 저장한다.

JWT 안에 있는 정보는 암호화하는 것이 맞는 이유는 local pc에 계속 남아있는 정보이기 때문에, 서버단에서 복호화해서 사용할 것이기 때문이다.
front에서 JWT 안에 암호화된 사용자 정보를 사용하진 않지만 서버에서 사용해야 하기 때문에 JWT안에 사용자 정보들이 암호화되어 들어가야 한다.

Local Storage

Vue store는 브라우저의 tab을 닫으면 초기화가 되기 때문에
local storage에서 토큰이 있는지 확인할 수 있어야 한다.
따라서 local storage에 토큰이 있으면, 해당 토큰으로 사용자 정보를 조회해서 vue store에 다시 저장해주어야 하는 로직이 있어야 한다 !

이걸 위한 token으로 사용자 정보를 조회하는 api가 있어야 한다.

왜 Local Storage에 저장해야돼?

쿠키 : 쿠키는 API 요청시마다 따로 셋팅해서 값을 넘겨주지 않아도, 알아서 쿠키정보가 서버로 전송이 되는데 이 점이 편리할 것 같지만 모든 웹 요청마다 네트워크 트래픽이 발생한다는 단점이 있다.

Session Storage : Vue Store와 마찬가지로 브라우저가 닫히면 초기화됨

4. Refresh Token을 DB에 저장하는 이유

예시로 Access Token의 만료일시가 1시간,
Refresh Token의 만료일시가 3일인 경우
Access Token(1)이 만료 되었을 때
Refresh Token(1)을 확인해서
새로운 Access Token(2)와 Refresh Token(2)를 발급한다.
이 때 Refresh Token(1)은 아직 만료가 되지 않았기때문에
접근이 가능하다는 보안적인 문제가 발생하므로
Refresh Token은 DB 사용자 테이블에 저장되어야 하고
검증시 DB에 저장된 Refresh Token을 비교하는 방법으로 보안을 강화할 수 있다.

Access Token과 Refresh Token의 만료일시를 동일하게 하면 되잖아?

이건 서비스 방침의 차이이다.

Access Token과 Refresh Token의 만료일시를 비슷하게 잡는 경우
예를 들어 Acess, Refresh Token 둘다 만료가 1시간이라고 가정했을 때, 사용자가 1시간동안 어떠한 API요청도 안한 경우.

즉 우리의 서비스를 1시간동안 사용하지 않았으면 로그아웃을 시키겠다.
혹은 Access Token은 만료가 1시간, Refresh Token은 1일이라고 가정했을 때는

사용자가 1시간 동안 어떠한 요청을 하지 않았더라도, 1일 미만으로 다시 요청을 하면 다시 로그인하지 않아도 되게끔 하겠다. 하지만 1일이 지났으면 로그아웃이 되도록 하겠다.

이런 차이가 있는 것이다. 하지만 1번처럼 만료일시를 비슷하게 잡는 경우라도 Access Token과 Refresh Token의 만료일시를 완전히 동일하게 해선 안되고 Refresh Token의 만료일시가 조금이라도 더 길어야한다. 그렇게 봤을때는 결국 DB에 저장하고 비교를 해주는 처리가 필요할 수 밖에 없다.

5. 토큰을 Parameter에 담아서 안넘기고 Request Header에 담아서 보내는 이유는 뭐야?

일종의 .. 국룰?
http에서 필드값을 보낼때 쓰는 규약 Authorization
인증 토큰값들은 헤더의 Authorization name을 사용하는게 일반적으로 규약 , 표준 .. 이게 있는데 굳이 parameter로 넘길 이유가 없다. parameter에는 온전히 해당 API에 넘겨야 하는 파라미터 값만 넘기고 인증 Token은 헤더에 담아 보낸다.