인증과 인가 개념 및 보안 흐름

세션 (Session )

- 전통적으로 많이 사용되는 방식으로, 서버가 사용자의 로그인 상태를 기억하는 방식

 

동작 흐름 

1. 사용자 로그인

● 사용자가 아이디/비밀번호 로그인을 시도합니다.

2. 세션 정보 생성 및 저장

● 서버는 로그인 정보가 유효하면, 사용자를 위한 고유한 세션 ID를 생성하고 이 정보를 서버 메모리나 데이터베이스에 저장합니다.

3. 세션 ID 전송

● 서버는 생성된 세션 ID를 클라이언트 (브라우저)에게 보내고, 브라우저는 보통 이 ID를 쿠키에 저장합니다.

4. 요청과 검증

● 이후 클라이언트는 서버에 요청을 보낼 때마다 쿠키에 담긴 세션 ID를 함께 보냅니다.

● 서버는 이 세션 ID를 받아 저장된 세션 정보와 비교하여 사용자를 식별하고 요청을 처리합니다.

 

JWT (Json Web Token ) 

최근 웹/앱 환경에서 널리 사용되는 방식으로, 서버가 로그인 상태를 저장하지 않는 (stateless) 인증 방식입니다.

서버가 상태를 저장하지 않으므로 JWT 자체에 모든 인증 정보가 담겨있습니다.

 

● 동작 흐름
1. 사용자 로그인

2. 토큰 생성 및 전송 - 서버는 로그인 정보가 유효하면, 사용자의 정보와 권한, 만료 시간 등을 담은 암호화된 토큰 ( Access Token)을 생성하여 클라이언트에게 보냅니다. 서버는 이 토큰을 저장하지 않습니다.

3. 토큰 저장 ( 쿠키 : 헤더 ) : 클라이언트는 전달받은 토큰을 로컬 스토리지나 쿠키에 저장합니다.

4. 요청과 검증 : 이후 클라이언트느 서버에 요청을 보낼 때마다 HTTP 헤더에 토큰을 실어 보냅니다. 서버는 이 토큰의 서명을 검증하여 유효성을 확인하고 요청을 처리합니다.

 

● 장점

○ 무상태 ( Stateless ) 및 서버  확장성 

- 서버가 토큰을 저장하지 않으므로 서버의 부하가 줄고, 여러 서버로 확장하기 용이합니다.

- 서버가 토큰을 사용하지 않아도 유저를 식별할 수 있는 이유는, JWT 자체에 모든 인증 정보가 담겨있기 때문입니다.

 

○ 유연성 

- 웹뿐만 아니라 모바일 앱 등 다양한 클라이언트 환경에서 사용하기 편리합니다. 

 

● 단점

○ 토큰을 탈취되면 만료될 때까지 악용될 수 있습니다.

○ 세션 ID보다 토큰의 크기가 더 큽니다.

○ 즉시 로그아웃 처리가 어려움

면접 질문 !!!
" 세션과 JWT는 정말 중요합니다 !! "

 

웹 애플리케이션 보안 흐름

Session이든, JWT든 서버가 '무언가'를 발급해줍니다.

이 무언가가 Session 방식에서는 유니크한 Session Key 이고, JWT 방식에서는 JWT (토큰) 인 것입니다.

또한, 매 요청마다 동일하게 클라이언트는 session key 혹은 JWT를 항상 같이 보내주어야합니다.

 

인증 (로그인)

이거 좀 헷갈릴수 있으니까 알아두면서 학습 하면 도움이 될 수도 있을 것 같습니다.

JWT와 Session 의 차이는 인증 차이이며 로그인 설계상 서로 다르게 설계 될 수 있습니다.

회원 정보가 일치하는지 확인 후 회원 정보가 일치 하면 쉽게 말해서 '출입증' 전용 입출입증을 주는거라고 보면 편할 것 같네요.

설계상 Session 될수도 있고, JWT 가 될 수도 있습니다. 한가지 의문인건 JWT랑 Session의 차이를 명확하게 나눠 관리 하는 방식이 아닌 선택 요소로 사용 되는데 원래는 Session의 사용 방식을 선호 했지만 최근부터 JWT Json Web Token 방식이 널리 사용 되고 있고 서버가 사용자 로그인 상태를 저장하지 않는 인증 방식 즉, 서버는 각 요청을 독립적으로 처리하고, 이전 요청의 상태를 기억하지 않는다는 의미라고 보면 된다. 요청 자체에 사용자 정보와 권한 확인에 필요한 모든 데이터를 담아서 보내도록 설계합니다.

 

Stateless 인증 vs Stateful 인증 비교

 

 

인가 (권한 확인)

말 그대로 인가는 권한이라 보면 편하겠음