Session, JWT, OAuth이란?

 

1. 인증을 구현하는 방식

 

로그인한 유저 혹은 특정 권한이 필요한 정보를 전달할 때 '인증'이 필요해진다.

이걸 구현하는 방식에는 크게 Session, Token, OAuth 등이 있다.

 

 

 

2. Session (세션)

개념:

• 세션은 서버 측에서 사용자에 대한 상태 정보를 저장하는 방식이다.
• 사용자가 로그인하면 서버는 세션을 생성하고, 세션 ID를 클라이언트에게 쿠키로 전달한다.
• 클라이언트는 이후 요청 시 쿠키를 통해 세션 ID를 서버에 전달하여 인증을 받는다.

작동 방식:

1. 사용자가 로그인하면 서버는 고유한 세션 ID를 생성하고, 이를 서버 메모리나 데이터베이스에 저장한다.
2. 세션 ID는 클라이언트에게 쿠키로 전달한다.
3. 클라이언트는 이후 요청마다 이 쿠키를 포함시켜 서버에 전송한다.
4. 서버는 쿠키의 세션 ID를 확인하여 해당 사용자의 정보를 조회하고 인증을 처리한다.

장점:

• 서버에서 상태를 관리하므로 보안이 상대적으로 우수하다.
• 세션 데이터는 서버에 저장되어 클라이언트에서 조작이 불가능하다.

단점:

• 서버 혹은 DB에 상태를 저장하기 때문에 서버 메모리 사용량이 증가할 수 있다.
  -  이걸 보완하기 위해 Redis같은 sessionId 보관용 DB를 따로 쓰기도 한다. (입출력 빠름)
• 확장성이 낮아 서버 간 세션 동기화가 필요할 수 있다.

 

 

3. JWT (JSON Web Token)

 

개념:

• JWT는 클라이언트 측에서 상태 정보를 저장하고 전송하는 방식이다.
• JWT는 JSON 형식으로 인코딩된 페이로드와 서명으로 구성된다.
• 인증 정보는 토큰 자체에 포함되며, 서버는 토큰을 검증하여 인증을 처리한다.

작동 방식:

1. 사용자가 로그인하면 서버는 JWT를 생성하고, 이를 클라이언트에 전달한다.
2. 클라이언트는 이후 요청마다 JWT를 포함시켜 서버에 전송한다 (일반적으로 HTTP 헤더에 포함).
3. 서버는 토큰의 서명을 검증하고, 페이로드에서 사용자 정보를 추출하여 인증을 처리한다.

장점:

• 서버에서 상태를 관리하지 않으므로 확장성이 우수하다.
• DB까지 조회하지 않아도 되어 DB 부하가 적다.
• 여러 도메인 간에 쉽게 사용할 수 있다.

단점:

• 클라이언트에서 토큰이 조작될 수 있으므로 서명 검증이 필수이다.
• 토큰이 탈취되면 만료 시간까지 사용될 수 있어 보안에 주의해야 한다.
  - 공격자가 탈취하면 만료될 때까지 계속 쓸 수 있다. 그래서 엑세스 토큰의 유효기간을 짧게 해놓는 편.

 

 

3. OAuth (Open Authorization)

개념:

• OAuth는 리소스 소유자가 제3자 애플리케이션에 자신의 리소스에 대한 접근 권한을 위임하는 프로토콜이다.
• 주로 소셜 로그인, API 접근 권한 위임 등에 사용된다.

작동 방식:

1. 사용자가 제3자 애플리케이션에서 리소스 소유자에게 인증 요청을 보낸다.
2. 리소스 소유자는 권한 부여 서버를 통해 사용자를 인증하고, 권한을 부여한다.
3. 권한 부여 서버는 액세스 토큰을 제3자 애플리케이션에 전달한다.
4. 제3자 애플리케이션은 액세스 토큰을 사용하여 리소스 서버에 접근한다.

장점:

• 리소스 소유자가 자신의 자격 증명을 제3자 애플리케이션과 직접 공유하지 않아도 된다.
• 다양한 권한 범위와 만료 시간을 설정할 수 있다.

단점:

• 설정과 구현이 복잡할 수 있다.
• 각 서비스마다 권한 부여 절차가 다를 수 있다.

요약

• Session: 서버 측에서 상태 정보를 관리하고, 클라이언트는 세션 ID를 쿠키로 전달하여 인증.
• JWT: 클라이언트 측에서 상태 정보를 관리하고, 토큰 자체에 인증 정보를 포함하여 서버에 전달.
• OAuth: 제3자 애플리케이션이 리소스 소유자의 리소스에 접근할 수 있도록 권한을 위임하는 프로토콜.