MSA OAuth 로그인 이슈 다루기(device_id and device_name are required for private IP)

dasd412·2023년 1월 13일
0

MSA 프로젝트

목록 보기
22/25

문제 상황

게이트 웨이를 거쳐서 Google OAuth 인증이 되지 않는다. 대신, 직접 인증 서비스 포트를 호출하면 인증 및 회원 가입이 성공한다.

시큐리티 설정

   @Override
    protected void configure(HttpSecurity http) throws Exception {
        JwtAuthenticationFilter authenticationFilter=new JwtAuthenticationFilter(authenticationManagerBean(),facade);
        authenticationFilter.setFilterProcessesUrl("/auth/login");

        http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and()
                .addFilter(corsFilter)
                .formLogin().disable()
                .httpBasic().disable()
                .authorizeRequests().anyRequest().permitAll()
                .and()
                .csrf().disable();

        http.logout()
                .logoutUrl("/logout")
                .deleteCookies("refresh-token");

        http.oauth2Login()
                .userInfoEndpoint()
                .userService(oAuth2Service)
                .and()
                .successHandler(oAuth2Service::onAuthenticationSuccess);

        http.addFilter(authenticationFilter);
    }

구글 리디렉션 URI 설정 상황

URL1은 게이트 웨이를 경유할 때이며, URL2는 게이트웨이를 경유하지 않고 직접 인증을 시도할 때를 나타낸다.

안될 때

URL

http://localhost:8062/writer/oauth2/authorization/google

어플리케이션 로그

gatewayserver_1     | 2023-01-13 03:03:15.987 DEBUG [gateway-server,31f7af952b5c8360,31f7af952b5c8360,true] 1 --- [or-http-epoll-7] c.d.a.g.filter.TrackingFilter            : diary-cor
relation-id generated in tracking filter: 99f7b2fc-cca7-44a8-a50a-8a4dd5e3a2c4.
gatewayserver_1     | 2023-01-13 03:03:15.998 DEBUG [gateway-server,31f7af952b5c8360,31f7af952b5c8360,true] 1 --- [or-http-epoll-7] c.d.a.g.filter.ResponseFilter            : adding co
rrelation id to the outbound headers.31f7af952b5c8360
gatewayserver_1     | 2023-01-13 03:03:15.998 DEBUG [gateway-server,31f7af952b5c8360,31f7af952b5c8360,true] 1 --- [or-http-epoll-7] c.d.a.g.filter.ResponseFilter            : complete 
outgoing request for http://localhost:8062/oauth2/authorization/google.

게이트웨이 서버에서 리퀘스트 필터와 리스폰스 필터를 모두 거치고 있다.
하지만 인증 서비스에서 작성한 OAuth 로직을 거친 흔적은 남아있지 않다.

결과

될 때

URL

http://localhost:8082/oauth2/authorization/google

어플리케이션 로그

writerservice_1     | 2023-01-13 02:59:11.980  INFO [writer-service,6939498273703ea0,6939498273703ea0,true] 1 --- [nio-8082-exec-1] c.d.a.w.a.s.security.OAuth2Service       : load user
 by oauth :null
writerservice_1     | Hibernate: select writer0_.writer_id as writer_i1_1_, writer0_.created_at as created_2_1_, writer0_.updated_at as updated_3_1_, writer0_.email as email4_1_, write
r0_.name as name5_1_, writer0_.password as password6_1_, writer0_.provider as provider7_1_, writer0_.provider_id as provider8_1_ from writer writer0_ where writer0_.name=?
writerservice_1     | 2023-01-13 02:59:12.272  INFO [writer-service,6939498273703ea0,6939498273703ea0,true] 1 --- [nio-8082-exec-1] c.d.a.w.a.s.security.OAuth2Service       : after aut
hentication success : null
writerservice_1     | 2023-01-13 02:59:12.272  INFO [writer-service,6939498273703ea0,6939498273703ea0,true] 1 --- [nio-8082-exec-1] a.w.a.s.s.JWTTokenWriterIntoResponseBody : writing j
wt token into response body ...
writerservice_1     | 2023-01-13 02:59:12.275  INFO [writer-service,6939498273703ea0,6939498273703ea0,true] 1 --- [nio-8082-exec-1] .d.a.w.a.s.s.r.i.RefreshTokenServiceImpl : updating 
refresh token in refresh token service : null
writerservice_1     | Hibernate: select writer0_.writer_id as writer_i1_1_0_, writer0_.created_at as created_2_1_0_, writer0_.updated_at as updated_3_1_0_, writer0_.email as email4_1_0
_, writer0_.name as name5_1_0_, writer0_.password as password6_1_0_, writer0_.provider as provider7_1_0_, writer0_.provider_id as provider8_1_0_ from writer writer0_ where writer0_.wri
ter_id=?

게이트웨이 서버를 거치지 않기 때문에 상관관계 id를 발급해주지 않는다. 로그에 null로 찍히는 값들이 있는데 바로 게이트웨이에서 지급하는 상관 관계 id이다.

그것을 제외하곤, 인증 로직이 제대로 작동한다.

결과

accessToken이 발급된다. 그리고 회원 가입 로직도 작성해놨기 때문에 db에도 잘 저장된다.


시도 해본 것

상관 관계 id 추적하기

안될 때, 상관 관계 id는 발급해준다. 그래서 한 번 집킨에다 질의를 해봤다.

302는 리다이렉트이며, Client Address는 안될 때 화면의 private address와 동일하다.

도커 private address 확인하기

docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' (도커 컨테이너 id) 를 활용해서
private address를 확인하니 위 집킨 Client address와 동일한 주소다.


흠... 해결은 아직 못했다. 그래도 생각나는 해결책은 다음과 같다.

  1. 게이트웨이 서버가 직접 인증까지 처리해준다.
  2. 게이트웨이 서버에서 인증 서비스로 리다이렉트 할 때 어떤 처리를 한다.

1.의 경우, 현재 프로젝트를 많이 뜯어 고쳐야 해서 손이 많이 간다. 그리고 게이트웨이가 할 일이 많아지는 것 같아서 응집성에서도 별로인 것 같고, 게이트웨이의 무상태성을 해친다.

2.가 그나마 현실적인 것 같은데... 관련 지식이 없다. 쩝

profile
아키텍쳐 설계와 테스트 코드에 관심이 많음.

0개의 댓글