지난 Feign Client 공부에 이어서 HeaderCoonfiguration을 왜 설정해주는지 이해하기 위해 공부하다가 session과 token 기반의 인증 특징들에 대해 알게되었다.
https://x-ojm.tistory.com/12?category=978307
기존 RestTemplate을 적용하여 Client.java를 구현하였을 때는 함수 내 header에 직접 token을 넣어 작성했는데,
FeignClient의 경우 configuration을 설정해줌으로서 Client별로 적용되어야 하는 설정을 정의할 수 있다.
그 중 @Bean RequestInterceptor로 정의하는 configuration함수에서는 여러 메소드에 대하여 공통으로 사용하는 header를 추가할 수 있도록 구현할 수 있다.
나의 경우는 token을 response하는 class를 정의하여 아래와 같은 내용으로 구현하였다.
@ToString
@NoArgsConstructor
@AllArgsConstructor
@EqualsAndHashCode(callSuper = false)
public class tokenResponse extends GenericResponse {
@Setter
@Getter
private Map<String, String> data;
public String getToken() {
return this.data.get("token");
}
}
login 시 token을 response하고 request session에 넣음 ▼ client에서 서버에 api를 호출할 때 configuration을 통해 request session의 token을 보냄 & view에서 session 정보를 통해 메뉴 접근 제한 등 구현 |
1. Session 기반 인증
세션 기반인증을 위해 Session 과 Cookie 가 사용된다. 다음 Flow 로 인증 절차가 진행된다.
- 유저가 로그인을 하고 세션이 서버 메모리 상에 저장된다. 이 때 세션을 식별하기 위한 Session Id 를 기준으로 정보를 저장한다. - 브라우저에 쿠키로 Session Id 가 저장된다. - 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request 에 Session Id 를 쿠키에 담아 전송한다. - 서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session Id 를 비교하여 Verification 을 수행한다. |
Session 기반 인증은 다음과 같은 장단점을 갖는다.
+ 세션 기반 인증 방식은 구현이 상당히 명확하다는 장점이 있다. 또한 실제 서버에서 로그인 상태 확인이 굉장히 유용하다.
+ 상대적으로 안전하다. 서버측에서 관리하기 때문에 클라이언트 변조에 영향받거나 데이터의 Stale (손상) 우려가 없다.
- 유저들의 세션에 대한 정보를 서버 메모리에 들고 있게 된다는 부담이 있다.
- 서버 메모리에 세션 정보가 저장되기 때문에 Scale Out / Scale In 이 부담이 될 수 있으며, 결국에는 유저 상태에 무관하게 동작할 수 있도록 Data-Driven 아키텍처가 요구된다.
- 멀티 디바이스 환경에서 로그인 시 신경써줘야할 부분들이 생긴다.
2. Token 기반 인증
Token 기반 인증의 방법으로 많은 웹 서버들은 JWT(JSON Web Token) 을 사용한다.
Token 기반 인증 방식과 Session 기반 인증 방식의 가장 큰 차이점은 유저의 정보가 서버에 저장되지 않는다는 점이다.
- 유저가 로그인을 하고 서버에 세션을 이용해서 정보를 기록하는대신, Token 을 발급한다. - 클라이언트는 발급된 Token 을 저장한다 (일반적으로 local storage 에 저장한다.) - 클라이언트는 요청 시 저장된 Token 을 Header 에 포함시켜 보낸다. - 서버는 매 요청시 클라이언트로부터 전달받은 Header 의 Token 정보를 Verification 한 뒤, 해당 유저에 권한을 인가한다. |
Flow 에서 차이를 확인할 수 있듯, Session 기반 서버가 서버측에 정보를 기록하는 반면, Token 기반 인증은 Token 에 대한 Verification 만 수행할 뿐 저장은 클라이언트에서 수행한다.
Token 기반 인증은 다음과 같은 장단점을 갖는다.
+ 클라이언트에 저장되기 때문에 서버의 메모리에 부담이 되지않으며 Scale 에 있어 대비책을 고려할 필요가 없다
+ 멀티 디바이스 환경에 대한 부담이 없다.
- 상대적으로 Stale (손상) 의 위험이 크다.
- 결국 구현을 하다보면 서버측에 token blacklist 를 관리하게 될 가능성이 있고 그렇게 되면 서버측 메모리의 소모가 발생하게 된다
- Token 은 일반적으로 Session ID 보다 길다.
- XSS 공격에 취약할 수 있어 가능한 민감한 정보는 포함시키지 않을 필요가 있다.
아래 블로그에 잘 정리되어 이해하기 쉬웠다!
'Web > Else' 카테고리의 다른 글
[Maven]빌드하여 jar 파일 만들기 (0) | 2021.11.16 |
---|---|
[Web]HttpSessionListener, AtomicInteger (0) | 2021.11.15 |
[Web]Maven LifeCycle (0) | 2021.11.04 |
[Web]multipart/form-data (0) | 2021.10.28 |
[Web]Url 주소 가져오기 (0) | 2021.10.25 |