로그인 방식

개념

로그인은 세션기반 인증방식 또는 토큰기반 인증방식으로 구현된다.
HTTP의 특징은 stateless하다는 것이 있다. HTTP 요청을 통해 데이터를 주고 받을 때 요청이 끝나면 요청한 사용자의 정보 등을 유지하지 않는 특징이 있다는 것이다.
따라서 HTTP 기반으로 로그인 기능을 구현했을 때 로그인 상태를 어떻게 유지해야 하는가?라는 의문이 생긴다.
이를 가능하게 해주는 방식이 세션기반과 토큰기반의 2가지로 나뉜다.

세션기반 로그인 프로세스

1. 로그인 -> sessionId 생성 -> 서버에서 세션ID를 쿠키로 설정해서 클라이언트에 전달
2. 클라이언트가 서버에 요청을 보낼 때 해당 세션ID를 쿠키로 담아서 전에 로그인했던 아이디인지 확인
3. 로그인을 유지

세션기반의 단점

• 사용자의 상태에 관한 데이터를 서버에 저장했을 때 로그인 중인 유저의 수가 늘어난다면 서버의 메모리 과부화가 일어날 수 있다.
• DB 중 RDBMS에 저장한다면 직렬화 및 역직렬화에 관한 오버헤드가 발생한다.

토큰기반인증방식

토큰 기반 인증방식은 state를 모두 토큰 자체 만으로 처리하며 토큰을 처리하는 한 서버를 두고 다른 컨텐츠를 제공하는 서버는 모두 stateless하게 만드는 방식이다.
모놀리식한 구조 하에 인증을 구현하게 되면 어느 한 군데가 망가지면 인증체계까지 모두 에러가 나서 어떤 기능도 사용할 수 없는 상태가 될 수 있다.
보통의 MSA식 구조 하에서는 인증 서버를 따로 만들어서 토큰을 인증서버를 통해 관리하게 된다.
토큰은 주로 JWT(Jason Web Token)을 사용한다.
인증서버에서 인증로직을 거쳐 JWT(access 토큰, refresh 토큰)를 생성한 뒤 클라이언트에서 access 토큰을 HTTP header - Authorization 또는 Cookie에 담아 인증이 필요한 서버에 요청하는 방식이다.

JWT 방식의 장점

1. 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함되어 있기 때문에 별도의 인증 저장소가 필요 없다.
2. 다른 유형의 토큰과 비교했을 때 경량화되어 있다. SAML과 비교해보면 확연히 짧다.
3. 디코딩했을 때 JSON이 나오기 떄문에 직렬화, 역직렬화가 간편하다.

JWT 방식의 단점

1. 토큰이 비대해질 경우 서버과부화를 일으킬 수 있다.
2. 토큰이 탈취당하는 경우 디코딩했을 때 데이터를 볼 수 있다

주의할 점

access 토큰을 얻은 후에 요청할 때는 HTTP Header - Authorization 또는 Cookie에 담아 요청을 하게 되는데 권장되는 규칙이 있다.

• Bearer {token} 으로 토큰값 앞에 Bearer라는 문자열을 붙여서 토큰기반 인증방식이라는 것을 알려준다.
• https를 사용해야 한다.
• 쿠키에 저장한다면 sameSite: 'Strict'를 써야 한다.
• 수명이 짧은 access token을 발급해야 한다.
• url에 토큰을 전달해선 안된다.

토큰 탈취에 대비하는 방법

1. Access 토큰의 수명을 짧게 하여 탈취된 토큰의 유효 기간을 최소화한다. 필요할 때만 Refresh 토큰을 통해 새로운 Access 토큰을 발급받는다.
2. Refresh Token을 사용하여 민감한 작업을 수행하려고 할 때 추가적인 사용자 인증단계를 요구한다. 예를 들어 IP 주소, 디바이스 정보 등을 이용하거나 google authenticator를 이용한 2FA(2 factor authentication)을 이용한다.
3. 쿠키에 HttpOnly 및 Secure를 걸어서 관리한다.

 

 

 

출처

CS 지식의 정석 | 디자인패턴 네트워크 운영체제 데이터베이스 자료구조 - 큰돌

https://www.inflearn.com/course/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A9%B4%EC%A0%91-cs-%ED%8A%B9%EA%B0%95/dashboard