스프링 시큐리티, Google Login 연동

1. 스프링 시큐리티(Spring Security)

막강한 인증(Authentication)과 인가(Authorization)(혹은 권한부여)기능을 가진 프레임워크

보안을 위한 표준이라고 보면 되며, 인터셉터, 필터 기반의 보안 기능을 구현하는 것보다 스프링 시큐리티를 통해 구현하는 것을 적극 권장.

 

로그인 기능을 id/password 방식보다는 구글, 페이스북, 네이버 로그인과 같은 소셜 로그인 기능 사용

직접 구현해야할 경우 로그인 시 보안, 회원가입 시 이메일 혹은 전화번호 인증, 비밀번호 찾기, 비밀번호 변경, 회원정보 변경을 구현해야 하는데 OAuth 로그인 구현을 하면 이와 같은 것들을 구글, 페이스북, 네이버 등에 맡겨 서비스 개발에 집중할 수 있음.

 

spring-security-oauth2-aytoconfigure 라이브러리 사용할 경우 스프링 부트 2 -> 1.5

Spring Security Oauth2 Client 라이브러리 사용

이 책 외에 스프링 부트 2 방식의 자료를 찾고 싶은 경우 2가지 확인

- spring-security-oauth2-autoconfigure 라이브러리 썼는지 확인

- application.properties 혹은 application.yml 정보가 차이가 있는지 확인

스프링 부트 1.5방식에서는 url 주소를 모두 명시해야 하지만, 2.0방식에서는 client 인증 정보만 입력하면 됨.

enum으로 대체됨, CommonOAuth2Provider라는 enum이 새롭게 추가되어 구글, 깃허브, 페이스북, 옥타의 기본 설정값은 모두 여기서 제공. 이외에 다른 소셜 로그인(네이버, 카카오 등)을 추가한다면 직접 다 추가해주어야 함.

 

2. 구글 서비스 등록

승인된 리디렉션 URI

-서비스에서 파라미터로 인증 정보를 주었을 때 인증이 성공하면 구글에서 리다이렉트할 URL

-스프링 부트2 버전의 시큐리티에서는 기본적으로 {도메인}/login/oauth2/code/{소셜서비스코드}로 리다이렉트 URL을 지원하고 있음. 

-사용자가 별도로 리다이렉트 URL을 지원하는 Controller를 만들 필요가 없음, 시큐리티에서 이미 구현해 놓은 상태입니다. 

-현재는 개발 단계이므로 http://localhost:8080/login/oauth2/code/google로만 등록

-AWS 서버에 배포하게 되면 localhost 외에 추가로 주소를 추가해야하며, 이후 단계에서 진행

 

scope=profile,email

기본값이 openid,profile,email이기 때문에 많은 예제에서는 이 scope를 별도로 등록하지 않고 있음.

강제로 profile,email을 등록한 이유는 openid라는 scope가 있으면 Open Id Provider로 인식하기 때문

이렇게 되면 OpenId Provider인 서비스(구글)와 그렇지 않은 서비스(네이버/카카오 등)로 나눠서 각각 OAuth2Service를 만들어야 함.

하나의 OAuth2Service로 사용하기 위해 일부로 openid scope를 빼고 등록함.

 

스프링 부트에서는 properities의 이름을 application-xxx.properties로 만들면 xxx라는 이름의 profile이 생성되어 이를 통해 관리할 수 있음. 즉, profile=xxx라는 식으로 호출하면 해당 properties의 설정들을 가져올 수 있음. 호출하는 방식은 여러가지가 있음.

application.properties에서 application-oauth.properties를 포함하도록 구성

 

구글 로그인을 위한 클라이언트 ID와 클라이언트 보안 비밀은 외부에 노출되면 안되므로

gitgnore에 등록

 

3. 구글 로그인 연동

User 클래스를 그대로 사용하지 않는 이유

User 클래스에 직렬화를 구현하지 않았다는 에러 남

-User 클래스가 엔티티이기 때문에 엔티티 클래스에는 언제 다른 엔티티와 관계가 형성될지 모름

예로 @OneToMany, @ManyToMany 등 자식 엔티티를 갖고 있다면 직렬화 대상에 자식들까지 포함돼

성능 이슈, 부수 효과가 발생할 확률이 높음. 그래서 직렬화 기능을 가진 세션 Dto를 하나 추가로 만드는 것이 이후

운영 및 유지보수 때 많은 도움이 됨.

 

4. 로그인 테스트

{{#userName}}

머스테치는 다른 언어와 같은 if문을 제공하지 않고 true/false 여부만 판단함

그래서 머스테치에서는 항상 최종값을 넘겨줘야 함.

userName이 있다면 userName을 노출시키도록 구성함

 

a href="/logout"

스프링 시큐리티에서 기본적으로 제공하는 로그아웃 URL

개발자가 별도로 저 URL에 해당하는 컨트롤러를 만들 필요가 없음

(SecurityConfig 클래스에서 URL을 변경할 수 있음)

 

{{^userName}}

머스테치에서 해당 값이 존재하지 않는 경우에는 ^ 사용

userName이 없다면 로그인 버튼을 노출시킴

 

a href="/oauth2/authorization/google"

스프링 시큐리티에서 기본적으로 제공하는 로그인 URL

로그아웃 URL과 마찬가지로 개발자가 별도의 컨트롤러를 생성할 필요가 없음

 

---

5. 세션 저장소로 데이터베이스 사용하기

애플리케이션 재실행하면 로그인이 풀림

-세션이 내장 톰캣의 메모리에 저장되기 때문

 

기본적으로 세션은 실행되는 WAS의 메모리에서 저장되고 호출됨.

메모리에 저장되다 보니 내장 톰캣처럼 애플리케이션 실행 시 실행되는 구조에선 항상 초기화됨.

배포할 때마다 톰캣이 재시작됨.

2대 이상의 서버에서 서비스하고 있다면 톰캣마다 세션 동기화 설정을 해야함. 

그래서 실제 현업에서는 세션 저장소에 대해 다음의 3가지 중 한 가지 선택

 

1) 톰캣 세션 사용

-일반적으로 별다른 설정을 하지 않았을 때 기본적으로 선택되는 방식

-이렇게 될 경우 톰캣(WAS)에 세션이 저장되기 때문에 2대 이상의 WAS가 구동되는 환경에서는 톰캣들 간의 세션 공유를 위한 추가 설정이 필요

 

2) MySQL과 같은 데이터베이스를 세션 저장소로 사용

-여러 WAS간의 공용 세션을 사용할 수 있는 가장 쉬운 방법

-많은 설정이 필요 없지만, 결국 로그인 요청마다 DB IO가 발생하여 성능상 이슈가 발생할 수 있음.

-보통 로그인 요청이 많이 없는 백오피스, 사내 시스템 용도에서 사용

 

3) Redis, Memcached와 같은 메모리 DB를 세션 저장소로 사용

-B2C 서비스에서 가장 많이 사용하는 방식

-실제 서비스로 사용하기 위해서는 Embeded Redis와 같은 방식이 아닌 외부 메모리 서버가 필요

 

레디스와 같은 서비스에 별도로 사용료 지불해야 함. 사용자가 없는 현재 단계에서는 데이터베이스로 모든 기능을 처리하는게 부담이 적음.

 

세션을 위한 테이블 2개(SPRING_SESSION, SPRING_SESSION_ATTRIBUTES)가 생성됨, JPA로 인해 세션 테이블이 자동 생성됨.

세션 저장소를 데이터베이스로 교체

 

이후 AWS로 배포하게 되면 AWS의 데이터베이스 서비스인 RDS(Relation Database Service)를 사용하게 되니 이때부터는 세션이 풀리지 않음.

 

6. 네이버 로그인

스프링 시큐리티에선 하위 필드를 명시할 수 없음. 최상위 필드들만 user_name으로 지정 가능하므로 

네이버의 응답값 최상위 필드는 resultCode, message, response들이므로 스프링 시큐리티에서 인식 가능한 필드는

저 3개 중에 골라야 함. 본문에서 담고 있는 response를 user_name으로 지정하고 이후 자바 코드로 response의 idfmf

user_name으로 지정

 

---

03/05

 

전체 테스트를 해보면 롬복을 이용한 테스트 외에 스프링을 이용한 테스트는 모두 실패함.

문제

1. CustomOAuth2UserService를 찾을 수 없음

CustomOAuth2UserService를 생성하는데 필요한 소셜 로그인 관련 설정값들이 없기 때문에 발생한다. 

application.properties 파일은 자동으로 가져오지만 application.oauth.properties는 test에 파일이 없다고 가져오는 파일은 아니기 때문이다. 

-test에 application.properties 파일 추가하여 해결

 

2. 302 Status Code

스프링 시큐리티 설정 때문에 인증되지 않은 사용자의 요청은 이동시키기 때문, 이런 API 요청은 임의로 인증된 사용자를 추가하여 API만 테스트해볼 수 있도록 함.

-스프링 시큐리티 테스트를 위한 여러 도구를 지원하는 spring-security-test를 build.gradle에 추가

 

3. @WebMvcTest에서 CustomOAuth2UserService을 찾을 수 없음

@WebMvcTest는 CustomOAuth2UserService를 스캔하지 않기 때문

 

@WebMvcTest는 @ControllerAdvice, @Controller를 읽음, @Repository, @Service, @Component는 스캔 대상이 아님. 

그러므로 SecurityConfig는 읽었지만, SecurityConfig를 생성하기 위해 필요한 CustomerOAuth2UserService는 읽을 수가 없어 에러 발생

-스캔 대상에서 SecurityConfig 제거

 

추가 에러 

@EnableJpaAudiging으로 인해 발생, 최소 하나의 @Entity 클래스 필요, @WebMvcTest이다 보니 당연히 없음.

@EnableJpaAuditing가 @SpringBootApplication와 함께 있다보니 @WebMvcTest에서도 스캔하게 됨. 

그러므로 @EnableJpaAuditing과 @SpringBootApplication 둘을 분리

-Application.java에서 @EnableJpaAuditing 제거

 

-WebMvcTest는 일반적인 @Configuration은 스캔하지 않음

 

 

스프링 시큐리티 적용으로 깨진 테스트를 적절하게 수정

 

이번 장에서 배운 것

- 스프링 부트 1,5와 스프링 부트 2에서 시큐리티 설정의 차이점

-스프링 시큐리티를 이용한 구글/네이버 로그인 연동 방법

-세션 저장소로 톰캣/데이터베이스/메모리DB가 있으며 이중 데이터베이스를 사용하는 이유

-ArgumentResolver를 이용하면 어노테이션으로 로그인 세션 정보를 가져올 수 있다는 것

-스프링 시큐리티 적용 시 기존 테스트 코드에서 문제 해결 방법