1. JWT
앱은 id 비번을 항상 넘기지 않으면 사용자가 누군지 확인할 수 없는 이슈가 있었다.
세션 키가 저장되지 않기 때문.
초창기:
웹에 글 쓸 경우 최초 요청 : ID/PW
요청 : 제목/내용
요청 : 제목/내용
앱 요청 : ID/PW
요청 : 제목/내용/ID/PW
요청 : 제목/내용/ID/PW
ID PW의 원문이 단말기에 저장되는 문제가 있었음
만료시킬 수 있는 계정
-test1 / 1234 계정 자체를 id와 비번으로 취급하는게 아니라,
이것과 동일하게 사용할 수 있는 무언가를 하나 더 만
앱시작 -> 아이디 비번 입력 -> 앱이 서버에게 아이디 비번이 유효한지 물어봄 ->
유효하면 아이디/비번 영구 저장 -> 글쓰기 HTTP POST title, body, id, pw
토큰
-> 아이디, 비번을 입력 -> 앱이 서버에게 아이디 비번이 유효한지 물어봄 ->
유효하면 서버가 토큰을 발급해줌 -> 유효하면 앱은 토큰을 영구 저장한다. -> 글쓰기, 좋아요시 토큰을 건내준다.
토큰 장점
앱에서 id와 pw를 가지고 있을 필요가 없다.
토큰 단점
매번 select를 해야한다. -> 캐시로 극복 가능
세션 -> 세션에 값이 있는지 없는지
토큰 값에 의미있는 데이터를 저장할 수는 없나? -> JWT
유효성 체크를 CPU연산만으로 할 수 있다. 데이터를 담을 수 있는 토큰 이다.
JWT에 의미있는 정보를 담을 수 있다.
if
{"id":1, "name"홍길동, "age":11}
JWT 디코딩을 통해서 권한 레벨, 번호, 이이디 등을 건내준다.
JWT 는 단순한 base 64로 인코딩 디코딩한 결과기에 신뢰도가 떨어질 수 있다.
시크릿키는 워터마크 같은 것. 데이터의 신뢰성을 보장한다.
만약 개인정보가 중간에 바뀐 경우는 JWT내의 정보가 최신화 되지 않기 때문에 키의 재발급이 필요하다.
JWT는 유효기간 전에 만료시키는게 불가능 하다. 그러니까 JWT 키 자체를 짧게 가져갈 수 있다.
리플레쉬 토큰 등
-> 애초에 DB에 토큰이 들어가 있으면 정당한 토큰인지 채크할 수 있다.
매번 DB에 접속하는 비용을 감소시키기 위해 캐시를 Redis에 걸어둘 수도 있다.
