Portfolio

OAuth2 기본 Flow는 session 방식 OAuth2 기본 Session 방식 분석하기 OAuth2AuthorizationRequestRedirectFilter OAuth2LoginAuthenticationFilter Session → Cookie 방식으로 Custom 하기 ETC 신버전과 구버전 차이

OAuth2 기본 Flow는 session 방식

OAuth2는 기본적으로 Session 방식의 인증을 제공한다.

실제 OAuth2LoginAuthenticationFilter에 객체 멤버 변수를 보면 RequestRepository에 HttpSessionxxx 구현체와 InMemoryxxxRepository 구현체들을 볼 수 있다.

그리고 사용자에게 보여질 화면에서 사용되는 RedirctFilter에서 csrf 관련 문자열을 삽입하여 외부 Authorization Server와 교환하는 과정을 포함해 OAuth2 인증을 정상적으로 수행하지만, 해당 처리과정은 세션 기반이다.

OAuth2 기본 Session 방식 분석하기

OAuth2AuthorizationRequestRedirectFilter

Redirect 필터에서 Code Grant 방식임을 확인하고 if 내부를 보면 saveXXXX라는 메소드가 호출된다.

authorizationRequestRepository 구현체를 보면 HttpSessionOAuth2XXX 구현체가 있음을 명확히 확인할 수 있다. 또한 내부 save 메소드안에서 getSession() 메소드를 호출하며 set 포로퍼티 메서드 또한 알 수 있다.

OAuth2LoginAuthenticationFilter

또한 OAuth2LoginAuthenticationFilter에서 attemptXXX 메소드를 호출하여 인증을 진행하면서 중간에 Repository에 들려 무언가를 지우는 행위가 있을 것이다.

AuthorizationRequestRepository 구현체를 보면 여기도 HttpSessionOAuth2AuthorizationRequestRepository 이다.

HttpSessionOAuth2AuthorizationRequestRepository 에서 보면 getSession()을해서 세션에 값을 저장한다.

또한 OAuth2LoginAuthenticationFilter 에 보면 return 문 바로 위헤 authorizedClientRepository.saveAuthorizedClient 메소드를 호출하는 것을 보면 구현체 이름이 InMemoryOAuth2XXXX라 명시되어 있다.

내부 안으로 들어가면 OAuth2AuthorizedClientRepository 상속받은 Authenticated XXX save메소드가 호출된다

이번엔 authorizedClientService에서 save메소드를 호출하고 있다.

service의 구현체를 InMomoryXXX인 것을 알 수 있고

실제로 메모리 기반으로 Map자료구조를 사용하여 특정 세션을 기억하고 있다

그러면 다중환경일 때, 다른 서버로 가는 사용자는 결국 재인증을 해야하는 불편함을 느낄 수 있다.

다시 정리해보면 AuthorizationRequestRepository(HttpSessionOAuth2AuthorizationRequestRepository 구현체), AuthorizedClientRepository(OAuth2AuthorizedClientRepository 구현체인 AuthenticatedPrincipalOAuth2AuthorizedClientRepository) 모두 세션인증 방식을 기본적으로 Spring Security OAuth2인증 과정에서 사용하고 있는 것이다.

Session → Cookie 방식으로 Custom 하기

세션기반이 아닌 다른 방식을 가져가기 위해서는 저 두가지의 기본 요소들을 교체해야 한다.

하지만 AuthorizationRequestRepository에서는 세션기반이 아닌 선택지가 없어 Custom 해야 한다.

AuthorizationRequestRepository<T> 인터페이스는 단 하나의 구현체만 가지고 있기 때문이다.

AuthorizedClientRepository는 구현체인 AuthenticatedPrincipalOAuth2AuthorizedClientRepository 에서는 내부적으로 service를 호출하면서 세션을 저장하는데 이 서비스를 교체하기만 하면 된다. 왜냐하면 이미 세션기반이 아닌 jdbc 기반으로 저장하는 것이 가능하기 때문에 교체 가능하다.

jdbc로 서비스 구현체를 교체하려면 해당 스키마가 등록되어질수 있도록 해야한다.

기본적으로 제공되어진 라이브러리 안의 스키마이다.

실제로 빈은 service자체에서 불러와지는 InMemory를 jdbc로 교체하여 메모리 기반 인증에서 탈 할 수 있게된다.

마지막으로 SecurityConfig에 빈으로 등록하면 AuthorizedClientRepository는 세션기반이 아니게 설정할 수 있다.

이제는 AuthorizationRequestRepository custom하여 쿠키 기반으로 바꾸어 볼것이다.

AuthorizationRequestRepository 상위 타입을 재구현하고

SecurityConfig에 빈으로 등록하면 AuthorizationRequestRepository도 세션기반이 아니게 설정할 수 있다.

실제로 해당 과정을 등록을 완료하면 AuthorizationRequestRepository의 구현체가 HTTPSession이 아닌 커스텀한 HTTPCookie 구현체가 들어가는 것을 볼 수 있다.

그리고 OAuth2LoginAuthenticationFilter에서 마지막 authorizedClientRepository에서 save메소드를 호출 내부에서는 InMemory 방식으로 저장을 했었다.하지만 이제는 메모리 기반으로 저장하는 것이 아닌 구현체가 jdbcOAuth2 구현체로 교체되었다.