TIL.Authentication (인증) Authorization (인가)

Authentication(인증)

로그인, 아이디와 패스워드 등을 통해 특정 서비스에 일정 권한이 주어진 사용자임을 인증 받는것

필요이유 - 서비스 사용추적

필요한것 - ID Email Password(노출되면 안됨)

Authorization(인가)

사용자가 한번 인증을 받은 후에 그 사용자가 특정 리소스에 액세스 할수 있는지 여부를 결정하는 프로세스

ex)

네이버에 로그인으로 인증을 한 후 블로그에 글을 쓰거나 댓글을 다는 등 내 계정으로 ‘만’ 할수 있는 활동을 시도할때 네이버가 나의 로그인 여부를 보고 허가 해주는 것

1. 로그인은 생각보다 무거운 작업이다.
   1. 데이터 베이스에 저장된 사용자 계정의 해시값을 꺼내온다
   2. 가져온 해시값을 사용자의 암호를 알고리즘으로 계산한 값과 일치하는지 확인하는 과정
2. 매 요청마다 아이디와 패스워드가 전송이 되는것도 보안상 위험하다.

쉽게 생각하면 현재 사용하고있는 id 카드가 있다. 발급과정은 인증이고

우리가 몇층에 갈수있는지 권한을 알려주며 다른층을 눌렀을때 아무런 반응이 오지않게 하는것이 인가 이다.

Session vs JWT

인가에 연관된 기술

Session

전통적으로 많이 사용 되어 온 방식으로 서버 기반의 인증방법

세션 id를 사용해서 어떤 사용자가 서버에 로그인 되어있다는 상태를 지속하는 것을 ‘세션'이라고 한다.

How to Authorization

1. 사용자가 로그인에 성공하면 세션을 발행
2. 세션을 브라우저 에도 저장하고 (ex)크롬에 session id 로 쿠키를 설정) 서버 메모리에도 저장한다.
3. 인가가 필요한 요청을 보낼때 서버에 세션값을 같이 보낸다
4. 서버는 메모리에 저장된 값과 세션값을 비교해서 맞는 값이 있으면 인가 해준다.

단점

• 세션이 서버에 저장되어 있기 때문에 사용자가 동시 다중 접속할때 메모리가 부족해진다.
• 서버가 재부팅 되어야하는 상황이 오면 서버의 메모리에 저장된 세션이 모두 날아가고 모든 사용자가 로그인이 튕겨서 다시 로그인 해야한다(DB에 넣어둔경우, 속도가 느려짐)

JWT (JSON Web Token)

사용자가 로그인을 하면 토큰을 주는데 이 토큰을 서버가 기억하고 있지 않는다.

• JWT Token 예

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

암호화된 3가지 데이터를 이어붙인 형태 (aaa.bbb.ccc)로 구성되어있다.

1. 헤더 : 알고리즘 (3번 서명값을 만드는데 사용될 알고리즘이 지정 되어있다.ex) H256, type이 들어감 언제나 JWT가 들어가 있다. )
2. 페이로드 : 토큰이 갖는 데이터
3. 서명 (signature): 1번 헤더에 정의된 알고리즘을 통해 암호화한 비밀번호의 값을 서버만 알고있다.

왜 세션을 대체 하지는 못할까....?

JWT는 세션처럼 모든 사용자들의 상태를 기억하고 있지 않다.

따라서 기억하는 대상들의 상태를 언제든 제어할수 있지 않다.

예를들어

세션을 이용해서 로그인을 만들경우 한 기기에서만 로그인 가능한 서비스를 만들고 싶을때 pc에서 로그인하면 핸드폰에서의 세션 값은 사용 못하게 하는등의 제어가 가능하다.

하지만 JWT는 이미 발행한 토큰을 뺏을수도 없다. 또한 토큰을 탈취당해도 무효화할 방법이 없다.

이에 대한 해결방안으로는 로그인시 accessToken, refreshToken 두개의 토큰을 주는 방법이 있다.

accessToken : 매번 인가를 받을때 사용하는 토큰 , 보통 수명이 짧다.

refreshToken accessToken의 수명이 다했을 때 accessToken을 재발행 받기위한 토큰으로 보통 2주정도의 유효기간을 가진다.