일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- Mac
- fastcampus
- Jenkins
- Docker
- 머신러닝
- Kafka
- 레디스
- config
- ec2
- java
- redash
- 로그인
- login
- spring
- EMR
- hive
- 자동
- 설정
- Zeppelin
- 자바
- 간단
- vue
- gradle
- Cluster
- aws
- 젠킨스
- SpringBoot
- 예제
- Redis
- 클러스터
- Today
- Total
코알못
[로그인] 로그인 유지는 어떻게 처리 하는 걸까? 본문
인증 정보를 주고 받는 방식은 두가지 방법이 있다.
- 쿠키 & 세션
- JWT
하나씩 알아보자!
# 쿠키 & 세션
1. 로그인
2. 사용자 정보 요청
따라서 쿠키의 만료시간에 따라 로그인 유지가 된다.
쿠키의 만료시간은 서버에서 쿠키 전달시 만료시간 설정 가능! (만료시간 설정 안할 시 브라우저 종료 시점에 쿠키가 사라짐)
개발자 도구를 열어 확인을 하면 session(세션 쿠키) 이라 저장된 값은 유효시간을 설정하지 않은 값이며, 기한이 있는것(지속 쿠키)은 쿠키 시간을 설정 한 것이다.
세션 쿠키는 메모리에 저장되어 메모리 유지 까지만 계속적으로 유효 하기에 브라우저 종료시 제거 되며, 지속 쿠키는 파일로 저장 되기에 브라우저 종료 되어도 유효 하다.
세션 쿠키는 메모리에 저장되기에 파일로 저장되는 지속 쿠키에 비에서는 보안에 취약하다.
네이버는 쿠키의 유효시간을 설정하지 않았는지 브라우저 종료시 로그인이 풀린다.
# JWT
1. 로그인 요청
2. 사용자 정보 요청
유효한지 체크 방법!
- JWT 값을 읽어 서명 값을 공용키로 복호화 하여 데이터(payload)와 비교시 일치한지 확인 (신뢰할 수 있는 토큰 체크)
- JWT 값을 읽어 만료 시간 체크 (토큰 만료 여부 체크)
JWT 방식의 경우 암호화가 아닌 base64 인코딩 형식이기에 사용자 정보를 쉽게 확인할 수 있어 중요한 정보는 담지 않는것이 좋으며, 꼭 담아야 한다면 암호화 하여 보내는 것이 좋다.
그리고 쿠키&세션 방식은 서버의 메모리 또는 redis에 정보를 저장하고 있어야 하기에 비용이 많이 들지만, JWT 방식의 경우 저장 없이 유효한 토큰인지만 체크하면 되므로 비용이 적게 든다.
두 방식 모두 데이터 변조에 대한 위험은 없다.
- 세션&쿠키 : 실제 데이터는 세션(서버)에 저장되어 있으므로 변조 불가.
- JWT : 데이터(Payload) 와 서명(Sinature) 된 값을 비교하여 데이터 변조를 확인하기에 서버 공용키를 알지 못하면 변조 불가.
* 서명된 값은 헤더 (Header)를 base64로 암호화 값과 데이터(Payload) base64로 암호화 값을 서버 공용키로 암호화한 값
# 참고
- JWT 구조
- JWT 값 확인 사이트
'ETC' 카테고리의 다른 글
[mac] 사용중인 포트의 PID 찾기 (0) | 2021.12.24 |
---|---|
[스프링부트] The temporary upload location [**/tmp/tomcat.*/work/Tomcat/localhost/ROOT]** is not valid (0) | 2021.09.27 |
[Jenkins] 젠킨스 배포 자동화 (with. newman) (0) | 2021.04.18 |
[Jenkins] 젠킨스 배포 자동화 (with. gradle, git) (0) | 2021.04.17 |
[Jenkins] 젠킨스 Mac 으로 설치 (0) | 2021.04.17 |