참고 : https://www.youtube.com/watch?v=y0xMXlOAfss&t=1014s (토니의 인증과 인가)
인증과 인가
인증
- 서비스에 등록된 유저의 신원을 입증하는 과정
인가
- 인증된 사용자에 대한 자원 접근 권한 확인
웹에서의 인증과 인가
인증 예시
- 유저가 회원가입 → 로그인
인가 예시
- 글을 쓸 수 있는 권한 획득
- 다른 사람의 글을 읽을 수 있음
- 다른 사람의 글을 수정 x
인증
간단히 짚고 넘어가기
- 서버 - 클라이언트는 HTTP를 통해
request 요청과 response 응답을 주고 받음 stateless- 서버에서클라이언트 측에서 보낸 한 요청과 다음 요청에 대해 연관관계가 존재하지 않게 되는 것
인증하기(Request Header 활용하기)
- user가 req.header에 id와 비밀번호를 담아 http://www.cocktailpick.com/login으로 요청
브라우저 처리
- 방금 들어온 url을 base64 인코더를 이용해서 인코딩 후 전달하는 방식
- 클라이언트 측에서 req header에 Authorization으로 token을 보내게 됨
- url에서 저 부분을 파싱 후 인코더를 통해 인코딩한 문자열을 가지고 있게 됨
- 그 다음 인코딩한 문자열을 요청 헤더 Authorization에 넣어 보내주는 개념
- 서버가 DB 체킹 후 DB에 실제 값이 있기 때문에 OK 사인을 보냄
문제점
- 사용자가 매번 로그인을 계속 해 줘야 함
ex - 글을 쓸 때 사용자가 로그인 한 다음 글 다 쓴 후 수정
- 인증 요청이 발생하게 됨
- 지금과 같은 상황이라면 매번 인증을 해줘야 되는 상황 발생
인증 유지하기(Browser 활용)
- 인증을 유지하기 위해 Browser에 있는 storage 활용
- storage → local storage, session storage, cookie
쿠키
- 쿠키에 간단하게 사용자 아이디, 비번을 집어넣음
- 사용자가 인증이 필요한 요청을 하게 될때 보내게 됨
- 사용자, 해커 입장(사용자 데이터가 raw하게 저장되어 있으니까)에서 편리한 방법이 되게 됨
안전하게 인증하기(Session 활용하기)
- 세션 - 인증된 사용자의 랜덤한 식별자와 랜덤한 문자열로 세션 id를 만들어 이를 응답헤더에 넘겨줌
- 그리고 클라이언트가 저장할 수 있도록 만드는 것
장점
- 클라이언트 쪽에서 사용자의 raw한 데이터를 가지고 있지 않아 보안에 장점이 생김
- 세션의 만료기간을 설정 가능 → 세션 값의 만료기간이 지나면 해커가 가져가게 되더라도 유효하지 않음
단점
- 탈취가 된 세션을 서버에서 삭제를 해 버리면 이 세션 자체를 이용하지 못하게 됨
문제점
- 서버스 확장 → 서버를 여러 개 두게 되면 로드 밸런서가 발생
- 한 번 인증 후 세션을 받았을 때, 다음 요청은 이제 세션으로만 이용을 해서 요청 보내게 됨 → DB 까지 요청 할 필요가 없음
- 이 상황에서 유저가 두 번째 인증이 필요한 요청을 하게 됨
- 근데 두 번째 인증 시 3번째 서버의 세션 DB로 접근을 해야하는데, 2번째 DB로 접근하여 에러가 발생
- 서버 하나하나 자체에서 세션을 관리하고 있어 생긴 문제
해결
- 세션 스토리지를 두어 해결
- 서버들에 있는 모든 세션들을 한 곳에서 관리
- 로드밸런서가 요청을 쏴도 결국에는 한 곳으로 요청을 보내 문제를 피할 수 있음
- 서버의 성능이 엄청나게 뛰어나지 않는 이상 수 많은 유저의 요청을 모두 감당하기 힘듬
효율적으로 인증하기(Token 활용)
- 처음으로 돌아가서 이제 사용자의 상태를 client, server가 아닌 요청과 응답에 담아보기
- 그것이 바로 TOKEN의 개념이다.
JWT
- 시크릿 키를 사용해 JWT를 생성
- 시크릿 키를 사용해 JWT의 인증 과정을 거침
- JWT 자체는 해독하기 쉬워 민감한 정보(비밀번호)를 담지 않음
- 시크릿 키가 노출되면 JWT 토큰도 끝 → 서버 내부에 잘 관리 해야함
JWT를 이용한 서버 - 클라이언트
- 요청을 보내면 서버는 시크릿 키를 통해 토큰을 생성
- 서버측은 쿠키를 통해 토큰 반환
- 클라이언트 측은 이제 요청 헤더에 토큰을 넣어 계속 요청(단, 비밀번호는 토큰에 포함되면 안됨 -> 보안 문제)
- 서버 측은 받은 토큰을 decoding하여 이 토큰이 유효한지 시크릿 키를 통해 검증 후 유저를 인증 시킴
- 서버가 여러대가 있을 시, 로드밸런서가 쏘는 것을 각자 자기가 가진 시크릿 키로 해독을 해서 진행하면 됨
- 요청을 반환하면 됨
- 현대의 서버 시스템의 중요한 확장성 → 서버가 늘어나도 인증이 가능
단점
- 액세스토큰이 탈취 당할 시 해커는 사용자와 같은 지위를 가져 사용자 처럼 접근하여 위험
해결
- 만료기간을 특정 시간으로 정해 놓으면 특정 시간이 지날 시 사용자, 해커 모두 사용할 수 없음
- 그래서 나온 개념이 Refresh Token
Refresh Token
- 요청을 보내면 Access Token, Refresh Token을 한 번에 생성
- 액세스 토큰은 저장 X, 리프레시 토큰만 저장소에 저장
- 이 둘을 응답으로 보내어 클라이언트가 둘 다 저장
- 액세스 토큰 → 저장 X
핵심
- 토큰으로 상태 관리를 하기에 따로 세션을 둘 필요가 없음
- 토큰 관리를 해야 함 → 결국 토큰도 탈취당할 수 있다!
FE