[Spring] 인증, 인가 - (쿠키, 세션, 토큰)

인증

식별 가능한 정보로 등록된 유저신원을 입증하는 과정 (회원가입/로그인)

인가

인증된 사용자에 대한 자원 접근 권한을 확인하는 과정 (권한부여)

 

 

즉 자원을 적절한 사용자에게 전달하기 위한 방법이다. (인증이 선행되어야 한다.)

 

구현하는방법은?

 stateless한 HTTP에서 인증과 인가를 어떻게 구현해야 할까?

 

크게 3가지 방법이 있다.

• 쿠키
• 세션
• 토큰

쿠키

1. 사용자가 로그인 요청을 서버에 보낸다, 서버에서 로그인 정보를 확인한다.

2. 인증이 완료되면 쿠키에 ID,PW(로그인 정보)를 담아서 사용자에게 전달한다.

 

이후 요청 부터는 사용자가 해당 쿠키를 이용하면 로그인 정보를 입력할 필요가없다

 

문제점

• 사용자의 정보를 쿠키에 담아서 사용하기 때문에 보안상 매우 취약하다

세션

1. 사용자가 로그인 요청을 서버에 보낸다, 서버에서 로그인 정보를 확인한다.

2. 인증이 완료되면 세션이라는것을 생성해서 사용자에게 전달해준다.

 

이후 요청부터는 사용자가 서버에 요청을 보낼때 해당 세션아이디를 같이 전송해서 인증을 한다.

 

장점

• 세션은 직접적인 정보를 사용하지 않기 때문에 보안상 더 안정적이다.
• 세션이 탈취되더라도 유효기간이 존재해서 보안상 더 안정적이다.
• 세션은 서버에서 관리하기 때문에 탈취당하면 세션을 서버에서 삭제할 수 있다.

 

문제점

• 서버를 여러개 만들경우 문제가 발생할 수 있다.
  • 세션을 서버별로 저장하기 때문에 로그인 요청을 보낸 서버가 이후 요청을 보내는 서버와 다를경우 문제가 발생한다.

 

해결방안

• 세션스토리지를 사용한다.
• 서버들이 각각 관리하는 세션을 한곳에서 저장,관리를 하도록 만든다.
  • 하지만 해당 방법 역시 요청이 많아진다면 세션을 저장하는 저장소에 문제가 발생할수 있다.

정리

• Session을 통한 인증/인가는 사용자가 로그인을 할 때 기존 로그인 정보와는 별도로 사용자를 식별할 수 있는 Session ID를 생성하고 이를 Session ID 저장소(서버 내부 or 외부)와 브라우저에 저장한 후, Session ID를 바탕으로 사용자를 인증하고 인가를 진행한다.
• Session은 로그인 정보를 직접 사용하지 않는다는 점에서 Cookie만을 사용한 인증/인가보다 안전하지만 Session ID 또한 탈취의 가능성이 있고, 무엇보다 Client의 상태를 서버에서 관리한다는 점이 HTTP 통신의 stateless 특성과는 거리가 있다.

 

토큰

세션 방식의 문제점을 해결하기 위해 나온 방식이 토큰방식이다. 대표적으로 jwt 토큰을 사용한다.

 

1. 사용자가 로그인 요청을 서버에 보낸다, 서버에서 로그인 정보를 확인한다.

2. 인증이 완료되면 SecretKey로 토큰을 만들어서 사용자에게 전달해준다.

 

이후 요청부터는 사용자가 서버에 요청을 보낼때 토큰을 같이 보낸다.

그러면 서버는 토큰이 유효한지 SecretKey로 판단해서 어떤 사용자인지, 만료되었는지 등을 확인한뒤 응답을 해준다.

 

장점

•  기존 로그인 정보를 그대로 사용하지 않는다.
• 서버에서 사용자 식별 값을 저장/관리하지 않는다.

 

그렇다면 어디서 구현해야 할까?

보통 필터와 인터셉터를 사용한다.

 

 

Interceptor와 Filter 모두 Controllor에 request가 도착하기 이전에 로직을 수행하거나 사용자에게 response가 전달되기 이전에 로직을 처리할 수 있도록 해준다.

 

다만 Interceptor는 Spring Context에 존재하고 Filter는 Web Context에 존재해 실행되는 시점이 다르다.

 

필터와 인터셉터란?

https://bangbaeking.tistory.com/71

[Spring] 필터(Filter)와 인터셉터(Interceptor)

 

• Interceptor는 특정 요청에만 전/후 로직이 필요할 경우 혹은 입/출력 데이터를 가공할 때 사용한다.
  • Controller 처리 이전(preHandle), Controller 처리 이후(postHandle), View 렌더링 이후(afterCompletion)에 로직이 수행된다.
• Filter는 모든 요청에 로직이 필요한 경우 혹은 request/response header와 같은 매개변수를 수정해야 할 때 사용한다.
  • Spring 영역의 Dispatcher Servlet에 요청에 도착하기 이전과 response가 Dispatcher Servlet을 떠난 이후에 실행되게 되죠.

따라서 Controller단이 아닌 Interceptor 와 Filter를 이용해서 인증,인가를 구현해서 문제점(코드중복, 유지보수)을 해결하자 (Spring Security는 Filter를 사용한다.)

 

(MSA 환경에서 인증,인가를 API Gateway에서 구현하면 공통로직을 처리할 수 있어 좋다.)

 

 

다음에 Spring Security, MSA와 API Gateway에 대해 알아보자.

Reference

• https://hudi.blog/session-consistency-issue/
• https://dev.gmarket.com/45