로그인기능을 구현한는 것도 어렵지만 무엇보다 로그인 상태를 '유지'하는거도 만만치 않게 어려운 일이다.
예로 들어 naver에 로그인을 했을 때 메일함을 들어가고 나올때, 보낸 메일함과 받은 메일함을 들어갔다 나올때 마다
로그인을 다시 하면 사용자들은 상당히 불편할 것이다.
그래서 서버에서 현재 사용자가 로그인을 했는지 안했는지를 알수 있어야 로그인 상태가 유지가 된다.
인증(Authentication). : 로그인
==> 내가 이 사이트에 가입된 회원임을 즉, 특정 서비스에 일정 권한이 주어진 사용자임을 아이디랑 비밀번호를 통해서 인증을 받는것
인가(Authorization)
==> 한번 인증을 받은 사용자가 이후 서비스의 여러기능을 사용할 때 매번 로그인 되어있음을 알아보고 허가 해주는것.
예) sns에 한번 로그인(인증)을 한뒤 내 계정의 사용자으로'만' 할 수 있는 활동을 할 때 내가 '로그인됨'을 인지하는것
Session 이란 ?
유저의 정보를 데이터 베이스에 저장하고 상태를 유지하는 도구
Session 특징
- 서버에서 생성되며 클라이언트에서 쿠키를 통해 저장된다.
- 클라이언트에서 요청을 보낼때 Session ID를 같이 보내면 요청을 보내는 사용자가 누구인지 서버에서 알수 있다.(매 요청마다 아이디와 비밀번호를 물어볼 필요가 없다.)
- Session ID는 데이터베이스에 저장이 되기 때문에 요청이 있을 떄 마다 매번 데이터 베이스를 확인 해야한다.
- 서버에서 데이터가 저장되기 때문에 클라이언트에 사용자 정보가 노출될 위험이 없다.
- 데이터베이스에 Session를 저장해야하기 때문에 Horizontal Scaling이 어렵다.
- 서버측에서 강제로 특정 유저를 쫒아낼수 있따. (EX) 넷플릭스 동시 사용자 4명 이상 제한
주요 단점
- 휘발성 메모리상에 저장할 경우 서버가 꺼지는 상황이나 에러 발생시 세션이 모두 날아가서 모든 사용자들이 다시 로그인을 해야한다.
- 여러명의 사용자가 동시에 방문하면 메모리가 부족해지며 저장 속도가 매우 저하된다.
- Horizontal Scaling이 어렵다.
(실 서버는 하나의 인스턴스로만 동작하지 않고 여러개의 병렬 서버로 운영이 된다. 이런 상황에서 각 서버간 세션을 동기화 하는 과정에서 메모리 소비가 크며 세션을 관리하기가 힘들어 진다.)
1. 사용자가 아이디와 비밀번호를 사용해서 로그인
2. 동일한 아이디가 있는,유효한 비밀번호 양식 등등 을 검증
3. 해당 사용자의 세션을 생성한 뒤 데이터베이스에 저장
4. 세션 정보를 쿠키에 담아 사용자에게 전송
1. 사용자가 쿠기가 담긴 요청을 보낸다.
2. 세션이 유효한 세션인지 검증
3. 쿠키에 담긴 세션과 데이터베이스에 있는 세션을 검색한 뒤비교
4. 해당 유저를 정보를 반환
JWT 란 ?
유저의 정보를 Base 64 인코딩된 String 값에 저장하는 도구
JWT 토큰은 인코딩(암호화)된 3가지 데이터를 이어 붙인 형태이다.
빨간색(header), 보라색(payload), 파란색(verify signature)로 구분이 된다.
payload를 디코딩해보면 json 형식으로 여러 정보들이 있다.
이 토큰들이 누가 누구에게 발급을 했는지, 언제까지 유효한지,서비스가 사용자에게 이 토큰을 통해 공개하기 원하는 내용( 사용자의 닉네임, 관리자 여부 등등) 하지만 간단히 bas64rul로 인코딩한 방식이기에 변조와 조작의 가능성이 높은 우려가 있다.
이를 위해 header와 signature가 있다.
header에는 타입과 알고리즘이 들어간다 타입은 늘 JWT가 들어며 알고리즘에는 signature(서명값)을 만드는데 사용될
알고리즘이 지정된다.
'header'와 'payload' 그리고 '서버에서 감춰놓은 비밀키' 이 셋을 암호화 알고리즘에 넣고 돌리면 3번 signature(서명값)이 나온다.
또한 암호화 알고리즘은 한쪽 방향으로만 계산이되어 서버만 알고있는 비밀값을 알 방법이 없어 안전하다.
즉, 요청이 오면 클라이언트에서 보낸 JWT토큰에서 header와 payload를 뽑아 서버에서 가지고 있는 비밀키를 조합해서
클라이언트에서온 시그니처(서명값)과 같은지 확인해서 인가를 판단한다.
JWT 특징
- Header,Payload,Signature로 구성되어 있으며 Base64로 인코딩 되어 있다.
- 서버에서 생성되며 클라이언트에 저장된다.
- 클라이언트에서 요청을 보낼때 JWT Token을 같이 보내면 현재 요청을 보내는 사용자가 누구인지 서버에서 알수 있다.(매 요청마다 아이디와 비밀번호를 물어볼 필요가 없다.)
- 정보가 모두 토큰에 담겨 있고 클라이언트에서 토큰을 저장하기 때문에 정보 유출의 위험이 있다.
- 데이터 베이스가 필요 없기 때문에 Horizontal Scaling이 쉽다.
1. 사용자가 아이디와 비밀번호를 사용해서 로그인
2. 동일한 아이디가 있는,유효한 비밀번호 양식 등등 을 검증
3. 데이터베이스에 따로 저장 없이 바로 사용자에게 토큰 전송
1. 사용자가 token정보과 함께 요청을 보낸다.
2. 기간지 지나지 않았는지, 해당 사용자의 토큰이 유요한지 검증
3. 토큰에서 사용자의 정보를 빼내어 사용자의 정보를 기반으로 데이터를 요청
Refresh Token & Access Token
- 두 토큰 모두 JWT 기반이다.
- Access Token은 API 요청을 할 떄 검증용 토큰으로 사용된다.
즉, 인증이 필요한 API를 사용할 떄는 꼭 Access Token을 Header에 넣어서 보내야 한다.
예) 게시물 삭제, 유저 정보 수정
- Refresh Token은 ACcess Token을 추가로 발급할 때 사용된다. Access Token을 새로고침(재발급)하는 기능이 있다.
- Access Token은 유효기간이 짧고 Refresh Token은 유효 기간이 길다.
- 자주 노출이 되는 Access Token은 유효기간을 짧게 해서 Token이 탈취돼도 해커가 오래 사용하지 못하도록 방지한다.
- 상대적으로 노출이 적은 Refesh Token의 경우 Access Token을 새로 발급 받을 때만 사용되기 때문에 탈취 가능성이 적다.
- 사용자는 Access Token과 Refresh Token을 둘 다 서버에 전송하여 인증하고 만료됐을 시 후자로 새로운 Access Token을 발급받는다.
- 공격자(해커)는 Access Token을 탈취하더라도 짧은 유효 기간이 지나면 사용할 수 없다.
즉, 인증 토큰(Access Token)이 탈취 당했을 시 피해를 최소한으로 하기 위해 Refresh Token을 사용한다.
학습 페이지
www.inflearn.com
'모카스터디 > ETC 개발 지식' 카테고리의 다른 글
| 페이지네이션[Pagination] (0) | 2024.03.09 |
|---|---|
| 리프레쉬 토큰을 왜 사용하는가 ? (0) | 2024.03.03 |
| Node.js란 ? (0) | 2024.03.02 |
| 서버 원격 깃허브에서 main에 있는거 한방에 pull로 당겨오기 (0) | 2024.02.29 |
| 프론트엔드 CORS 개념 정리 (2) | 2024.02.29 |