[JWT, Oauth]서브 도메인 분리와 인증 인가 서버 설계 소개

기존에 서비스A와 추가 개발 진행하고 있는 서비스B의 도메인이 추가하게 됨과 동시에, 통합 인증인가를 위한 서버를 별도로 구성하기하였다. 

 

기존 : www.domain.com

신규 : sub.doamin.com

 

 

서버의 구성은 다음과 같다.

 

 

각 서비스의 인증과 인가는 Auth Server와 통신하여 이루어 질 것이다.

 

여기서, 인증 권한은 크게 세션 과 토큰으로 나누어진다.

 

 

세션 VS 토큰 

 

1. 세션

 

세션으로 했을때 크게 두가지의 방법이 있다.

 

 1) 세션 복제 ( 네트워크를 통해 동기화)

 2) 중앙 집중식 세션 스토리지 ( Reds 등의 세션 저장소)

 

나는 톰캣의 세션 클러스터링을 통해 세션을 복제하는 방법을 사용한적이 있다.

네트워크 상태에 따라서 세션이 복제하는데 애를 먹은적이 있다.

원활한 통신환경이 구축되어야 할것 이다. 

 

 

세션을 통해 인증을 한다면 중앙 집중식으로 세션을 많이 사용한다.

 

 

2. 토큰

 

인증정보를 사용자 브라우저에 저장(쿠키 등) 하여 인증하는 방법이 있다.

위,변조가 불가하도록 암호화가 필요하다.

 

JWT 기반의 인증이나 Oauth 인증 방법 등이 있다.

 

토큰으로 발급 시 모바일 환경 등 특정 Client 종속되지 않는 환경에서 유리하다.

 

 

 

 

이 중에 필자가 채택한 인증 방법은 JWT토큰 발급 방식이다. 쿠키에 토큰을 저장하여 사용할 생각이다.

JWT 토큰은 사용하는 이유는 Auth Server와 통신하지 않고 각 resource 서버에서 인가가 가능하기 위함이다.

토큰에 정보를 저장 할 필요도 없기 때문에 용이하다.

 

 

쿠키와 토큰으로 인증인가 정보를 공유할것이며 권한처리는 각 API에서 처리하게 될 것이다.

 

 

 

 

 

 

인가코드 승인

AcessToken를 저장하고 관리한다면 좀 더 안전한 OAuth2 인가코드 승인 방식으로 진행도 가능할 것이다.

 

최초 인증 필요한 페이지에 진입시 Auth Server에서 로그인폼을 제공하고 로그인 시 JWT토큰을 제공하여 각 Site와 인증, 인가가 이루어 지도록 계획하고 있는 플로우이다.

 

이에 경우 Access Token 과 Refresh Token 발급이 이루어질 수 있다.

 

 

 

 

 

 

그이외에도 인증코드 발급을 생략한 플로우가 있다.

 

JWT토큰을 쿠키에 저장하여 사용한다면 이 플로우를 사용할 수 있을것 같다. (Oauth Implicit)

참고(JWT 토큰은 어디에 저장하는게 좋을까)

 

토큰을 검증하는 중 시간이 만료되었을 경우 다시 Auth server로 Redirect 하여 Access 토큰을 발급하도록 로그인 등으로 요청하는 방법이 있고 Refresh 토큰을 통해 서버간에 Token을 갱신하는 방법이 있다.

 

 

만약에 RefreshToken을 발급한다면 엄격한 관리가 필요하다.

발급된 IP를 기준으로 제한을 두거나 브라우저 핑거프린터 정보등을 통해 유효성 확인하는것이 좋다.

 

 

 

 

 

 

 

참고

Spring Security JWT