로그인이 복잡한 이유 1. 세션과 토큰

로그인이 뭔지 아세요?

Q. 로그인은 무엇일까?
A. 인증된 사용자라는 것을 알려주기 위한 기능

 

Q. 어떻게 구현해야 할까?
A. JWT 토큰

 

위의 내용은 이 글에 대한 요약이 아닙니다 ❌
공부를 하기 전에 생각한 제 대답입니다.
제가 어떻게 이해했고, 결론은 어떻게 내렸는 지 써보겠습니다.

 

알아볼까요

어떤 서비스에나 있는 로그인과 로그아웃은 간단해 보입니다.
그렇지만 이 인증과 인가 기능을 구현하기 위해서는 고려해야 할 것이 많습니다.

 

사용자의 정보가 털리지 않도록 보안을 지켜야 하고,

사용자가 서비스에 머무는 동안 로그인이 잘 되어 있도록 사용성을 중시해야 합니다.

 

로그인의 문제점

구현에 앞서서 알아야 하는 부분입니다.

로그인을 공부하다 보면 서버와 보안에 대해 알게 됩니다!

(또 여기서 모르는 용어 나오면 무한 학습 루프에 빠짐...ㅎ)

✅ HTTP의 비연결성 

로그인의 문제점은 HTTP 특성에 있습니다.
HTTP는 인터넷 상에서 데이터를 주고 받기 위한 통신 프로토콜이자 규약입니다.

클라이언트가 서버에게 요청을 보내면 서버는 응답을 보내는 과정을 통해 데이터를 교환합니다.
이렇게 요청과 응답의 처리 과정이 끝나면 HTTP는 연결을 끊어 버립니다.

 

이것은 HTTP의 비연결성이라는 특징입나다.

이 특징으로 인해 로그인이 까다로워집니다.

 

사용자의 로그인을 요청하고, 서버는 이에 관련해 응답합니다.
응답이 성공하여 로그인이 이루어졌습니다.

이렇게 한 번의 요청과 응답 과정이 이루어 졌으니 연결이 끊어집니다.
다음 요청부터는 사용자의 로그인 여부를 알 수 없어짐을 의미합니다.

 

사용자는 매 작업마다 로그인을 계속해야 합니다.
그렇다면 보안은 견고해지겠지만, 사용자는 굉장히 불편할거예요.

이러한 사용성 이슈를 막기 위해 인증을 계속 유지해야 합니다.

 

인증 유지 방법

1. Session ID를 이용하는 방식
2. 토큰을 이용하는 방식

🖥 Session 기반 인증

Session ID를 이용하는 방식은 아래의 순서로 이루어 집니다.

(C는 Client, S는 Server)

1. C: 로그인 요청
2. S: 세션 생성
3. S: 생성된 세션의 ID를 클라이언트에 응답
4. C: 클라이언트를 이 세션 ID를 저장하고 있다가 인증이 필요할 때 이 값을 서버에 전송
5. S: 서버는 세션을 불러와 유효한 값인지 확인

Q. 세션과 세션 스토리지는 같을까?
다릅니다!
여기서 말하는 Session은 Session Storage와 다릅니다.
세션은 서버에서 생성하고, 세션 스토리지는 클라이언트에서 관리합니다.

세션은 서버 기반 인증이기도 합니다.

🪙 Token 기반 인증

사용자가 토큰을 이용해서 자신의 신원을 확인하고, 자격 증명을 의미하는 토큰을 받는 프로토콜입니다.
현실 생활에서 토큰은 놀이공원의 티켓 역할이겠네요.

 

요청 -> 확인 -> 토큰 -> 저장소의 과정으로 진행됩니다.

1. 보통 아이디와 비밀번호를 서버에 보내 액세스를 요청합니다. (로그인 시도)
2. 서버가 확인하여 권한이 있는 사용자인지 확인합니다.
3. 확인 후에 서버는 토큰을 발급하고 로그인 요청에 응답합니다. (권한이 있다면 로그인 성공)
4. 이 토큰은 유효 기간동안 브라우저에 저장됩니다.

이 토큰은 천년만년 가지고 있을 수 없구요. 유효 기간이 있습니다.
이 기간동안 접근(Access)을 허용하는 Access Token을 받게 되는 것입니다.

유효 기간은 서비스의 정책에 따라 다르게 설정합니다.

 

로그인에 토큰을 왜 사용해야 하나요?

지금까지 세션과 토큰을 이용한 방법이 있다고 찾아 보았습니다.

 

과거에는 로그인 구현에 있어서 비밀번호에서 세션 기반 인증이 사용되었습니다.
현재는 주로 토큰 기반 인증방식을 사용하는데요.

 

세션 기반 인증 방식은 서버 측에서 유지보수가 필수적입니다. 이는 서버의 부담이 증가할 수 있겠죠.
그래서 Scale-out 인프라에서는 여러 대의 서버가 있는 경우, 요청이 분산되고 각각의 서버에서 처리합니다.

Scale-out: 인프라 확장을 위하여 서버를 여러대 추가해서 확장하는 방식
Scale-up: 기존 서버의 사양을 업그레이드하는 방식

 

1. 사용자가 로그인을 하고
2. 해당 사용자의 정보를 담은 세션 객체 생성

이 세션 객체(Session ID)들은 하나의 저장소(세션 스토리지)에서 관리됩니다.
여러 서버에서 공유되어야 하기 때문입니다.
이 때, 여러 서버끼리 이 세션 스토리지를 동기화하는 작업이 필요합니다.

 

이렇게 세션 방식은 서버 측의 부담이 큰 작업입니다.

그래서 이에 대한 대안이 바로 토큰 기반의 인증 방식입니다.

 

토큰은 사용자 인증에 필요한 정보를 담고, 이를 암호화하여 클라이언트에게 발급합니다.
서버 측에서 유지보수가 필요없기 때문에 토큰 기반 인증 방식이 선호되고 있습니다.

 

Q. 세션 스토리지가 서버에도..?
위에서 말하는 세션 스토리지는 서버에 있는 것입니다. 브라우저에 있는 세션 스토리지와는 다릅니다.
브라우저의 세션 스토리지는 클라이언트에서 사용하는 웹 스토리지입니다.

 

요약

• 로그인의 핵심은 보안과 사용성이다.
• 요청↔️응답 과정이 끝나면 연결이 끊어지는 HTTP의 비연결성때문에 인증 방식이 필요하다.
• Session 방식은 서버 측의 부담이 크고, Token은 그렇지 않다.

---

다음에는 JWT를 이용한 토큰 기반 인증에 대해서 자세히 알아 보겠습니다.

다음 글을 보기 전에 JWT와 토큰이 같은걸까? 에 대해 생각해보면 좋을 것 같습니다.