인증/인가를 구현하는 Session(세션)과 Token(토큰) 방식의 차이

인증과 인가가 무엇인지 알고, 이를 구현하기 위한 세션과 토큰 방식을 알아보고 차이를 비교해 보겠습니다.

 

인증

인증은 식별 가능한 정보로 사용자의 신원을 확인하는 과정입니다.

예시로는 로그인을 들 수 있습니다. 구체적으로 어떤 사이트의 회원일 경우 로그인을 통해 회원이 맞음을 인증하고, 인증 절차가 성공할 경우에만 서비스 이용이 가능한 경우를 말합니다.

인가

인가는 사용자가 특정 자원에 접근할 권한이 있는지를 확인하는 과정입니다. 인가는 인증을 바탕으로 사용자가 시스템 내에서 할 수 있는 행동을 결정합니다.

예시로는 사용자 페이지와 관리자 페이지의 접근 여부를 들 수 있습니다. 일반 사용자는 관리자 페이지에 접근할 수 없지만, 관리자는 접근이 가능한 것을 말합니다. 추가적으로 이 접근 여부는 로그인한 사용자를 바탕으로 행해지는 과정입니다.

 

 

세션 방식

최초 로그인 시 세션 방식

 

세션 기반 인증은 다음과 같은 과정으로 동작합니다.

1. 사용자가 loginId, password 정보를 전달하면 서버에서 해당 사용자가 맞는지 확인합니다.
2. 맞다면 서버에서 세션 ID를 생성합니다.  이때 값은 추정 불가능해야 하기 때문에 UUID를 사용하여 생성합니다.
3. 생성된 세션 ID(cH7jsl8Amh..)와 세션에 보관할 값(syoh)을 서버의 세션 저장소에 보관합니다.
4. 서버는 클라이언트에 세션 ID만 쿠키에 담아서 전달합니다.
5. 클라이언트는 쿠키 저장소에 JSESSIONID 쿠키를 보관합니다.

 

로그인 이후 접근 시 세션 방식

 

로그인 이후 접근했을 때 클라이언트는 요청 시 항상 JSESSIONID 쿠키를 전달하고, 서버에서는 클라이언트가 전달한 JSESSIONID 쿠키 정보로 세션 저장소를 조회해 로그인 시 보관한 세션 정보를 사용합니다.

 

이처럼 세션 방식에서는 서버에서 사용자의 상태를 관리하기 때문에 Stateful(상태유지)하다는 특징을 갖고 있습니다.

 

🤔 그렇다면 세션 방식의 장점과 단점은 무엇이 있을까요?

먼저 장점으로는 보안적인 이슈가 낮다는 것입니다.

세션에 만료기간을 설정할 수 있어 설정된 시간이 경과하면 세션이 자동으로 무효화되어 보안성이 강화됩니다.

또 특정 세션이 탈취당했을 경우 서버에서 삭제할 수 있기 때문에 세션을 Invalidation(무효화) 할 수 있습니다.

이처럼 세션 방식은 서버에서 사용자의 상태를 관리하기 때문에 위와 같은 장점을 가집니다.

 

단점으로는 서버를 여러 대로 확장할 경우 세션을 공유하거나 관리하는 추가적인 작업이 필요하다는 점입니다.

만약 최초 로그인 시 1번 서버에 세션 정보를 보관 후, 다시 인증 요청을 했을 때 2번 서버에 연결됐다면 이는 문제가 됩니다. 각각의 서버에서 세션을 관리하여 2번 서버에는 1번 서버의 세션 정보가 존재하지 않기 때문입니다.

따라서 별도로 중앙화된 세션 스토리지에 저장하는 방식을 적용하는 등 추가적인 작업이 필요하게 됩니다.

 

토큰 방식(JWT)

최초 로그인 시 토큰 방식

 

토큰 기반 인증(JWT)은 다음과 같은 과정으로 동작합니다.

1. 사용자가 loginId, password 정보를 전달하면 서버에서 해당 사용자가 맞는지 확인합니다.
2. 맞다면 시크릿 키를 이용해 토큰을 생성합니다.
3. 서버는 클라이언트에 토큰을 쿠키에 담아서 전달합니다.
4. 클라이언트는 쿠키 저장소에 access 쿠키를 보관합니다.

 

로그인 이후 접근 시 토큰 방식

토큰 방식의 경우 로그인 이후 접근했을 때의 요청 시 클라이언트로부터 넘어온 값을 시크릿 키를 통해 유효성을 검사합니다. 서명이 유효하다면 JWT의 페이로드를 통해 사용자의 정보(id, 이름, 권한, 토큰 발급 및 만료시간..)를 추출합니다.

 

이처럼 토큰 방식에서는 서버에서 사용자의 상태를 관리하지 않기 때문에 Stateless(무상태)하다는 특징을 갖고 있습니다.

 

🤔 마찬가지로 토큰의 장점과 단점은 무엇이 있을까요?

장점으로는 확장성이 좋다는 것입니다.

앞서 본 세션의 단점으로 각각의 서버에서 세션을 관리하여 추가적인 작업이 필요하다는 것을 확인했는데, 토큰 방식은 서버에서 사용자의 상태를 관리하지 않기 때문에 서버 간의 동기화가 필요하지 않습니다. 클라이언트가 재요청을 해도 각각의 서버 시크릿 키를 사용하여 복호화하면 되기 때문에 추가적인 작업이 필요하지 않습니다.

 

단점으로는 보안적인 이슈가 크다는 것입니다.

Access Token이 탈취당했을 경우 서버에서는 어떠한 조치도 취할 수 없습니다.

이러한 이유로 토큰 만료시간을 짧게 설정하는 방법이 있지만, 이 또한 본래의 사용자도 토큰을 사용할 수 없는 문제가 생깁니다.

때문에 Refresh Token이 만들어졌습니다.

 

 

Refresh Token이란?

Refresh Token은 Access Token이 만료된 후에도 새로운 Access Token을 발급받기 위해 클라이언트에게 제공되는 토큰으로, 인증 서버가 클라이언트를 재인증하지 않고도 새로운 Access Token을 발급할 수 있게 해 줍니다.

 

Refresh Token의 과정도 간단하게 확인해 보겠습니다.

사용자가 로그인할 경우 기존 토큰 방식인 Access Token에 Refresh Token을 추가적으로 발급하여 클라이언트에 전달합니다. Refresh Token은 데이터베이스나 인메모리 저장소(Redis)와 같은 곳에 저장하여 관리합니다.

 

Access Token이 만료되었을 경우

 

만약 Access Token이 만료되어 검증에 실패한다면 쿠키 저장소의 Refresh Token을 서버로 보내 유효성 검사를 한 이후에 새로운 Access Token을 발급받습니다.

 

이처럼 Access Token을 사용하면 보안적인 측면을 강화할 수 있습니다.

하지만 Refresh Token을 서버(데이터베이스)에서 관리함으로써 결국 사용자의 상태를 관리하게 되어 Stateful한 요소가 포함됩니다. 이로 인해 서비스는 완전한 Stateless 상태를 유지하지 않게 됩니다.

 

 

결론

• 세션 방식은 보안적인 이슈가 낮은 반면 서버를 확장할 경우 추가적인 작업이 필요하게 됩니다.
• 토큰 방식은 토큰을 탈취당했을 경우 서버에서 취할 수 있는 조치가 없어 보안적인 이슈가 크지만 서버를 확장해도 추가적인 작업이 필요 없기 때문에 확장성이 좋습니다.
• 추가적으로 토큰 방식의 보안적인 이슈로 만들어진 Refresh Token은 결국 서버에서 상태를 관리하기 때문에 기존 토큰 방식의 장점을 잃게 되는 단점이 존재합니다.

 

 

참고

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-2?srsltid=AfmBOoorHVi3G4Xel79pVbwWO32K3WAHl-vDNsNNpCtmKW4EDP7VBzcC

스프링 MVC 2편 - 백엔드 웹 개발 활용 기술 강의 | 김영한 - 인프런