웹 로그인과 Session 이해하기

컴퓨터 초보를 위한 로그인·인증 구조 입문 가이드

1. 들어가며

웹사이트를 이용하다 보면 다음과 같은 경험을 하게 됩니다.

• 한 번 로그인하면 여러 페이지를 이동해도 로그인 상태가 유지된다.

• 웹사이트를 닫았다가 다시 열어도 로그인되어 있는 경우가 있다.

• 일정 시간이 지나면 다시 로그인을 요구한다.

• 로그아웃하면 더 이상 내 계정으로 서비스를 이용할 수 없다.

이런 "로그인 상태를 어떻게 유지하는가?"를 이해하려면 다음 용어들을 알아야 한다.

Session, Cookie, JWT, Access Token, Refresh Token

처음 보면 어려워 보이지만 핵심 개념은 생각보다 단순하다.

2. 가장 먼저 알아야 할 것 — 로그인

사용자가 웹사이트에 로그인한다고 생각해 보자.

사용자
  │
  │ 아이디 + 비밀번호
  ▼
서버
  │
  │ 비밀번호 확인
  ▼
로그인 성공

서버는 사용자가 입력한 아이디와 비밀번호가 맞는지 확인한다.

이 과정을 일반적으로 Authentication(인증)이라고 한다.

Authentication

"당신이 정말 이 계정의 주인이 맞습니까?"

를 확인하는 과정이다.

예를 들어,

아이디: pion79
비밀번호: ********

를 서버에 보내고 서버가 올바른 사용자라고 판단하면 인증이 성공한다.

3. 로그인 후 가장 큰 문제

로그인에 성공했다고 끝나는 것이 아니다.

사용자가 로그인한 다음 다음과 같은 행동을 한다고 생각해 보자.

로그인
 ↓
내 프로필 보기
 ↓
게시글 보기
 ↓
게시글 작성
 ↓
내 설정 보기

서버 입장에서는 각각의 요청이 별도의 요청이다.

요청 1 → 서버
요청 2 → 서버
요청 3 → 서버
요청 4 → 서버

그러면 서버는 매번 생각해야 한다.

"이 요청을 보낸 사람이 누구지?"

그래서 서버가 사용자의 로그인 상태를 계속 확인할 수 있는 방법이 필요하다.

여기에서 Session이라는 개념이 등장한다.

4. Session이란?

Session을 아주 쉽게 표현하면 다음과 같다.

Session = 사용자가 로그인한 상태를 서버가 기억하고 있는 것

예를 들어 서버가 다음과 같이 기억한다고 생각하면 된다.

Session

ABC123
  ↓
사용자 ID = 79
사용자 = 홍길동
로그인 상태 = 로그인

사용자가 다음 요청을 보냈을 때,

Session ID = ABC123

라는 정보가 함께 전달되면 서버는

"ABC123은 홍길동의 로그인 상태구나."

라고 알 수 있다.

5. Session ID

서버가 사용자를 기억하기 위해 번호를 하나 만들어 줄 수 있다.

예:

Session ID

ABC123XYZ789

이 번호를 Session ID라고 한다.

서버에는 다음과 같은 정보가 연결되어 있을 수 있다.

ABC123XYZ789
       ↓
사용자 ID = 79
       ↓
홍길동
       ↓
로그인 상태

따라서 Session ID 자체가 사용자의 모든 정보를 담고 있는 것이 아니라,

"서버가 저장해 놓은 로그인 정보를 찾아가기 위한 식별자"

라고 이해하면 쉽다.

6. Cookie란?

그렇다면 브라우저는 Session ID를 어떻게 기억할까?

여기서 Cookie(쿠키)가 등장한다.

Cookie는 웹브라우저가 저장할 수 있는 작은 데이터이다.

예를 들어:

Cookie

session_id=ABC123XYZ789

브라우저는 이후 서버에 요청할 때 이 Cookie를 함께 보낼 수 있다.

브라우저
   │
   │ Cookie
   │ session_id=ABC123XYZ789
   ▼
서버

서버는 Session ID를 보고 사용자를 확인한다.

7. Cookie와 Session의 관계

여기가 매우 중요하다.

Cookie와 Session은 같은 것이 아니다.

간단히 그림으로 보면:

        브라우저                         서버

       Cookie                         Session
┌─────────────────┐             ┌──────────────────┐
│ session_id=ABC  │ ──────────→ │ ABC → 홍길동     │
└─────────────────┘             └──────────────────┘

즉,

Cookie

브라우저가 가지고 있는 정보

Session

서버가 가지고 있는 로그인 상태

라고 생각하면 된다.

8. Session 방식의 전체 과정

로그인 과정을 연결해 보면 다음과 같다.

① 로그인
   │
   ▼
② 아이디/비밀번호 확인
   │
   ▼
③ 로그인 성공
   │
   ▼
④ 서버가 Session 생성
   │
   ▼
⑤ Session ID 발급
   │
   ▼
⑥ 브라우저 Cookie에 Session ID 저장
   │
   ▼
⑦ 다음 요청부터 Cookie 전송
   │
   ▼
⑧ 서버가 Session ID로 사용자 확인

이를 그림으로 표현하면:

[사용자]
    │
    │ ID + 비밀번호
    ▼
[서버]
    │
    │ 로그인 성공
    ▼
[Session 생성]
    │
    │ Session ID
    ▼
[브라우저 Cookie]
    │
    │ 다음 요청
    ▼
[서버]
    │
    ▼
[Session 확인]
    │
    ▼
"홍길동이구나!"

9. Session에는 유효기간이 있다

로그인 상태를 영원히 유지하는 것은 보안상 좋지 않다.

그래서 Session에는 보통 유효기간이 있다.

예:

Session 생성
10:00
  ↓
11:00
  ↓
12:00
  ↓
Session 만료

이와 관련해서 다음과 같은 용어를 볼 수 있다.

• Session Timeout

• Session Expiration

• Session Lifetime

모두 기본적으로

"로그인 상태를 얼마나 오래 유지할 것인가?"

와 관련된 개념이다.

10. 로그아웃

사용자가 로그아웃하면 로그인 상태를 끝내야 한다.

Session 방식에서는 일반적으로 서버의 Session을 삭제하거나 무효화한다.

로그아웃
   ↓
Session 무효화
   ↓
기존 Session ID 사용 불가

따라서 이전에 가지고 있던 Session ID를 다시 보내도 서버는

"이 Session은 더 이상 유효하지 않다."

라고 판단할 수 있다.

11. JWT란?

여기서 또 다른 로그인 방식이 등장한다.

바로 JWT(JSON Web Token)이다.

Session 방식에서는 서버가 Session을 저장하고 있었다.

Session 방식

Session ID
   ↓
서버의 Session 저장소
   ↓
사용자 정보

JWT 방식에서는 서버가 사용자에게 Token을 발급한다.

개념적으로는 다음과 같다.

JWT

사용자 정보
만료 시간
기타 정보
서명

실제 JWT는 사람이 읽기 좋은 이런 형태가 아니라 긴 문자열로 표현된다.

eyJhbGciOiJIUzI1NiIsInR5cCI6...

12. JWT와 Token

JWT를 이해할 때 다음 관계를 기억하면 좋다.

JWT = Token을 표현하는 한 가지 형식

그리고 Access Token은 서버의 API 등을 이용할 때 사용자의 권한을 증명하기 위한 토큰이다.

예:

로그인 성공
    ↓
Access Token 발급
    ↓
브라우저가 보관
    ↓
API 요청
    ↓
Access Token 제출
    ↓
서버가 Token 확인
    ↓
요청 허용

13. Access Token

Access Token은 일반적으로 오래 사용할 수 있도록 만들지 않는다.

예를 들어:

Access Token

발급: 15:00
만료: 15:15

즉,

15분 동안만 사용할 수 있는 Token

으로 만들 수 있다.

이렇게 짧게 만드는 이유는 보안 때문이다.

만약 Access Token이 누군가에게 도난당하더라도 사용 가능한 시간을 줄일 수 있다.

14. "15분이면 15분마다 다시 로그인해야 하나?"

그렇지 않다.

여기서 Refresh Token이 등장한다.

예를 들어:

Access Token
유효기간: 15분

Refresh Token
유효기간: 7일

이라고 해보자.

사용자가 로그인하면:

로그인
  │
  ├── Access Token ──→ 15분
  │
  └── Refresh Token ─→ 7일

Access Token이 15분 후 만료되면 사용자는 다시 아이디와 비밀번호를 입력할 필요 없이 Refresh Token을 사용해 새로운 Access Token을 받을 수 있다.

Access Token 만료
        ↓
Refresh Token 제출
        ↓
서버가 확인
        ↓
새로운 Access Token 발급
        ↓
다시 서비스 이용

15. Access Token과 Refresh Token의 관계

쉽게 비유하면 다음과 같다.

Access Token

"지금 이 서비스를 이용할 수 있습니다."

Refresh Token

"새로운 Access Token을 발급받을 수 있습니다."

따라서:

Refresh Token
      │
      ▼
새 Access Token
      │
      ▼
서비스 이용
      │
      ▼
Access Token 만료
      │
      ▼
Refresh Token
      │
      ▼
새 Access Token

이 과정이 반복될 수 있다.

16. Session 방식과 Token 방식

대표적인 두 가지 구조를 비교해 보자.

Session 방식

브라우저
   │
   │ Session ID
   ▼
서버
   │
   └── Session 저장소
          │
          └── 사용자 정보

서버가 Session 정보를 가지고 있다.

Token 방식

브라우저
   │
   │ Access Token
   ▼
서버
   │
   └── Token 검증

서버가 Token을 확인하여 요청을 허용한다.

17. Cookie와 JWT는 경쟁 관계가 아니다

초보자가 자주 혼동하는 부분이다.

다음은 서로 다른 종류의 개념이다.

Cookie
→ 데이터를 저장하고 전달하는 방법

Session
→ 로그인 상태를 관리하는 개념

JWT
→ Token의 표현 형식

Access Token
→ API 이용 권한을 증명하는 Token

Refresh Token
→ 새로운 Access Token을 받기 위한 Token

따라서 다음과 같은 구조도 가능하다.

Cookie
  ↓
JWT Access Token 저장

즉 Cookie 안에 JWT를 넣는 방식도 가능하다.

18. 가장 중요한 용어 정리

19. 꼭 구분해야 하는 두 단어

마지막으로 Authentication과 Authorization을 구분하자.

Authentication

"너 누구야?"

예:

아이디 + 비밀번호
        ↓
홍길동 본인 확인

Authorization

"네가 이 작업을 할 권한이 있어?"

예:

홍길동
  ↓
관리자 페이지 접근
  ↓
관리자 권한이 있는가?
  ↓
Yes → 허용
No  → 거부

따라서 로그인 시스템에서는:

Authentication
       ↓
"누구인지 확인"
       ↓
로그인
       ↓
Authorization
       ↓
"무엇을 할 수 있는지 확인"

이렇게 연결해서 생각하면 된다.

20. 전체 내용을 한 장으로 정리

웹 로그인 시스템을 아주 단순하게 표현하면 다음과 같다.

                    [로그인]
                       │
                 ID + 비밀번호
                       │
                       ▼
                [Authentication]
                       │
                  본인 확인
                       │
             ┌─────────┴─────────┐
             │                   │
       Session 방식          Token 방식
             │                   │
       Session 생성          JWT 발급
             │                   │
       Session ID           Access Token
             │                   │
          Cookie              Cookie 등
             │                   │
             └─────────┬─────────┘
                       │
                       ▼
                  [서비스 이용]
                       │
                       ▼
                Access Token 만료
                       │
                       ▼
                Refresh Token
                       │
                       ▼
               새 Access Token
                       │
                       ▼
                  계속 이용

21. 초보자를 위한 최종 기억법

처음에는 모든 기술적인 내용을 외우려고 하지 않아도 된다.

다음 다섯 문장만 기억하면 된다.

1. 로그인은 "내가 누구인지 확인하는 것"이다.

2. Session은 "로그인한 사용자를 서버가 기억하는 것"이다.

3. Cookie는 "브라우저가 가지고 있다가 서버에 보내는 작은 정보"이다.

4. Access Token은 "서비스를 사용할 권한이 있다는 것을 증명하는 것"이다.

5. Refresh Token은 "Access Token이 만료되었을 때 새 Access Token을 받기 위한 것"이다.

이 다섯 가지를 이해하면 웹 개발 문서에서 등장하는 Session, Cookie, JWT, Access Token, Refresh Token이라는 단어가 더 이상 완전히 별개의 어려운 용어처럼 보이지 않는다.

그리고 실제 프로젝트의 로그인 코드를 볼 때는 먼저 다음 질문을 해보면 된다.

① 사용자가 로그인하면 무엇을 받는가?
       ↓
② Session인가? Token인가?
       ↓
③ Cookie를 사용하는가?
       ↓
④ Access Token은 얼마나 오래 유효한가?
       ↓
⑤ Refresh Token이 있는가?
       ↓
⑥ 로그아웃하면 무엇이 무효화되는가?

이 순서로 코드를 따라가면 로그인 시스템의 전체 구조를 훨씬 쉽게 파악할 수 있다.