[Spring] Spring Security setting과 에러 사항 수정 과정 기록과 OAuth2

Security  docs : 

Spring Security

---

🍺 이거 왜 ? 프로젝트 진행 중 특정 API를 외부에서 쓸 수 있도록 인증과정을 제거해달라는 요청이 있었고, 제거 후 프로젝트를 스테이지 서버에서 기동 

-> API는 자유롭게 쓸 수 있었으나, 관련된 내부 메소드에서 인증이 없는 경우 특정 기능을 사용하지 못하는 상황이 발생. 

 

Security 와 인증에 대해 정리 하고 넘어가기로 함.

 

 

작업한 프로젝트 버전 

Spring-boot :

• Maven: org.springframework.security.oauth:spring-security-oauth2:2.3.4.RELEASE
• Maven: org.springframework.security:spring-security-config:5.5.1
• Maven: org.springframework.security:spring-security-core:5.5.1
• Maven: org.springframework.security:spring-security-crypto:5.5.1
• Maven: org.springframework.security:spring-security-web:5.5.1

JAVA : 1.8 

 

Security & Oauth : 

• Maven: org.springframework.security.oauth:spring-security-oauth2:2.3.4.RELEASE
  • -> SPRING SECURITY 5.0부터 2.0대 버전 사용 가능.
• Maven: org.springframework.security:spring-security-config:5.5.1
• Maven: org.springframework.security:spring-security-core:5.5.1
• Maven: org.springframework.security:spring-security-crypto:5.5.1
• Maven: org.springframework.security:spring-security-web:5.5.1

 

 

 

---

Spring Security의 제공 기능 

1. Servlet API 통합
2. Spring Web MVC와의 선택적 통합
3. 인증 권한 부여를 포괄적로 확장하며 지원
4. 세션 고정, clickjacking, 사이트간 요청 위조(CSRF) 방지

웹 기반 인증 및 인가를 편하게 구현하도록 함.

 

🤖 stateless 한 HTTP위에서 인증 인가가 없다면 비밀번호와 아이디를 계속 입력해야 하는  불상사가 생길 수 도있다.

 

인증? : 사용자의 신원 확인 

인가? : 사용자가 특정 리소스에 접근하는 권한 또는 동작 수행 가능성을 지니고 있는 지 검증 - 접근 권한을 얻는 일

 

그래서 보통 쿠키 / 세션 / 토큰 방식으로 해결하지만 해결방식에 대해서는 생략. 

 

 

 

 

 

 

🤖 인증 과정은 다음과 같다.

 

---

로그인을 통한 인증 구조

 

 

 

1. 사용자의 요청 ( Request ) → 인터셉트 →
2. UsernamePasswordAuthenticationToken 생성
3. 인증 담당 — 아이디 - PW ( post -form 데이터로 생성 ) — Authentication 객체 생성 - 다른 필터로 전달하기 위함.
   1. 성공 시, 이후 프로세스 진행
   2. 실패 시, throws Authentication Exception
4. AuthenticationProvider에 객체 전달
5. UserDetailsService에서 Authentication 객체를 DB내에 존재하는 유저임을 조회
   1. 유저 세션을 생성 - 리턴 리턴 리턴 
6. 시큐리티컨텍스트(인메모리) 홀더에 저장
7. 유저 세션 ID와 함께 응답을 보낸다.

이후 사용자의 요청(쿠키) 에서 JsessionID를 검증 후 유효하다면 인증처리.

 

 

 

---

작업한 프로젝트의  SecurityConfig

 

🤖 Security 3.2 버전 이상부터는 XML 설정보다 조금 더 편한 자바 기반 어노테이션 설정(EnableWebSecurity)도 가능하다.

 

 

🤖 SecurityConfig는 WebSecurityConfigurerAdapter의 구현체이다.

 

 

 

 

 

 

다음과 같이 컨트롤러에서 사용 할 수 있는 어노테이션도 있다.

 

 

 

 

 

 

 

 

 

🤖 어노테이션에 의한 설정이라 하여

큰 차이가 있는 것은 아니며,  컨트롤러 별로 아래의 configure에서 세팅하는 Role을 컨트롤러 별로 세팅 할 수 있다는 차이점이 있다. 

 

아래와 세팅이 컨트롤러 어노테이션 세팅과 동일하다면, 시큐리티 설정에 의한 동작은 동일하다.

 

 

 

🤖 다음은 작업중인 프로젝트의 Configure 설정이다. 

  

인증과 인가를 동시에 필터로 체크하고있다. 

 

 

 

 

 

 

🤖  이번  특정 target API 인증 제거 작업 시 문제가 되었던 부분은 거의 대부분의 API의 시작지점인 /API/Studio/**의 부분이다.

 

 

🤖 특정 target API에 대한 인증 제거 설정과 기존의 API 시작지점에 대한 모든 인증 요구 설정이 충돌한다.

 

🤖 작업 시에는 강제로 target API에 대한 인증을 제거했지만 API내의 비즈니스 로직에서 인증에 따른 사용자 정보를 캐치하는 부분에서 에러가 나서 우회하는 식으로 작업을 수정했다. --> 미리 확인하고 수정했어야 했는데 코드를 꼼꼼히 보지 않고 작업부터 한게 요인..

 

 

 

 

 

 

🤖 configure 설정에서는 JwtAuthenticationFilter 와 JwtAuthorizationFilter를 사용하는데 다음에서 둘 다 살펴본다.

 

인증 필터는?

 

 

와 같이 UsernamePasswordAuthenticationFilter를 확장하고 있다. 

 

🤖 UsernamePasswordAuthenticationFilter는  사용자의 request에서 아이디와 패스워드를 파싱해서 인증 요청(UsernamepasswordAuthentication Token을 생성 -> Authenticationmanager를 구현한 객체에 인증 위임)을 한다.

이는, 

 

와 같이 구현하고, 다음과 같은 과정을 거친다고 보면 된다.

 

 

// UserDetailService의 상속과 구현체가 존재해야 한다.
Authentication authentication = this.getAuthenticationManager().authenticate(authenticationToken);

프로바이더는 실제 사용자 여부를 반드시 체크해야 한다.

 

🤖 위 과정에서AuthenticationManager를 통한 로그인 시도는 UserDetailService를 상속받은 PrincipalDetailService를 호출하고, 

loadUserByUserName 메소드를 통해 서비스의 DB에 있는 유저와 일치하는지 체크한다.

 

@Service
@RequiredArgsConstructor
public class PrincipalDetailService implements UserDetailsService {

    private final AuthRepository AuthRepository;

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        String loginId = username;
        Account userEntity = AuthRepository.selectUserByLoginId(loginId);
        if (ICNObjectUtility.isEmpty(userEntity)) {
            throw new UsernameNotFoundException("UsernameNotFoundException!!");
        } else {
            return new PrincipalDetails(userEntity);
        }
    }
}

 

 

 

🤖 다음은 4번 과정인 아이디와 패스워드를 통한 인증 성공시의 로직이다. 

 

 

 

작업중인 프로젝트는 쿠키를 통한 인증 모드와 헤더를 통한 인증모드로 나눠져 있다 ( 설정값 properties로 제어)

 

인증 성공 이후 레디스 캐시 서버에 토큰과 계정 로그인 아이디 등을 세팅한다.

 

// 토큰 생성 
accessToken = this.jwtUtility.generateToken(principalDetails, expTmAccess);
refreshToken = this.jwtUtility.generateToken(principalDetails, expTmRefresh);

// 쿠키
accessToken = this.jwtUtility.generateToken(principalDetails, expTmAccess);
refreshToken = this.jwtUtility.generateToken(principalDetails, expTmRefresh);

// response
response.addCookie(accessCookie);
response.addCookie(refreshCookie);

// redis 에 적재 
redisUtility.setData(refreshToken, principalDetails.getAccount().getLoginId(), Long.valueOf(expTmRefresh));

레디스에 Data 생성해서 기록하고, 리턴한다.

 

 

 

 

 

 

 

인가 필터는? 

 

 

BasicAuthenticationFilter를 확장한다. 

 

 

 

인증과 마찬가지로 작업중인 프로젝트에서 properties로 관리하는 인증 모드에 따라 분기가 나뉜다. (생략)

 

여기서도 마찬가지로 헤더 쿠키 인가 검증으로 본다. 

 

try {
    // request의 토큰을 검증 (쿠키)
    Cookie accessCookie = this.cookieUtility.getCookie(request, "accessToken");
    Cookie refreshCookie = this.cookieUtility.getCookie(request, "refreshToken");

    // Secret 키를 통한 JWT 검증
    loginId = JWT.require(Algorithm.HMAC512(this.Properties.getSecret())).build().verify(accessToken).getClaim("loginId").asString();

    // 로그인 사용자 검증 
     Account userEntity = commAuthRepository.selectUserByLoginId(loginId);
    PrincipalDetails principalDetails = new PrincipalDetails(userEntity);
    Authentication authentication = new UsernamePasswordAuthenticationToken(principalDetails, null, principalDetails.getAuthorities());

	// security session에 접근해서 Autehntication 객체를 저장한다.
	SecurityContextHolder.getContext().setAuthentication(authentication);

	// 저장한 객체는 다음과 같이 꺼내올 수 있다!
    // SecurityContextHolder.getContext().getAuthentication(authentication);

	// 성공일 경우 다음 과정 진행
	chain.doFilter(request, response);

} catch (JWTVerificationException e) {
	// 토큰 검증시 실패하거나 만료 인경우 refresh token 검증
    refreshCookie = this.cookieUtility.getCookie(request, "refreshToken");

    // redis 서버에서 refreshToken이 존재하는지 확인하고, 
    String redisLoginId = redisUtility.getData(refreshToken);

    // 다시 액세스 토큰을 발급한다.
	 String newAccessToken = this.jwtUtility.generateToken(principalDetails, expTmAccess);
    Cookie newAccessCookie = this.cookieUtility.createTokenCookie("accessToken", newAccessToken, expTmRefresh);
    response.addCookie(newAccessCookie);
    
} catch (Exception e ) {
	// 생략..
}

 

🤖 객체를 저장하고 꺼내오며 사용자의 정보에 대해 많은 것을 알 수 있게 되는데,

 

🤖 이 과정이 이번 수정 사항에서 많은 문제를 일으킨 부분이다. 

 

현재 프로젝트 내에서는 다음과같이 세션에 저장된 사용자 정보를 가져오는 코드가 존재하는데, 

 

문제는 이 세션 정보를 가져오는 사용처가 

 

 

정말 많다...

 

 

🍅 당연히 내가 작업했던 인증 인가 생략하는 특정 API OPEN 작업은 

   사용자가 최초 접근 -

   configurer에 의한  filter (인증 및 인가) -

   인가 session 에 사용자 정보 저장 -

   controller api 호출  -

   비즈니스 -

   종료     

 

     또는 비즈니스 - ( 사용자 검증 및 사용자 정보를 바탕으로 한 비즈니스 로직 )

 

과 같은 방식에서 두 번째 케이스인 사용자 정보를 쓰는 경우 문제가 된다.

 

 

수정한 인증과 인가를 생략한 API에 접근(당연히 생략됐으니 Session에는 사용자 정보가 없다!) 했는데,  사용자 정보를 검증하는 비즈니스 로직이 숨어있다면? -> null point Exception을 방어하지 않을 경우 그대로 500 Error 발생 혹은 방어 코드인 경우 정상적인 접근이 아니라는 Return을 받기 때문이다.

 

 

 

따라서, target API만!   반드시 필요할 경우 사용자 정보를 생략하는 식으로 수정방향을 잡았다.

또는 동일한 기능을 하는 신규 API 생성 ( 핉터의 범위에서 제외된 URI로)

 

---

그 외.

 

OAuth를 통한 로그인

 

 

Oauth : 구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제3자 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임(Delegated Authorization)받을 수 있는 표준 프로토콜.

 

 

 

 

Resource Owner = 사용자

Client = Resource Server의 자원을 이요하고자 하는 서비스, 보통 개발하고자 하는 서비스!

Authorization & Resource Server = 별개 혹은 하나로 구성 가능하며 , 구글 , 페이스북, 카카오와 같이 리소스를 가지고 있는 서버를 말함.

• 로그인 요청 - 구글계정으로 로그인하기 등이 해당.
  1. 구글(Authorization Server / Re - 줄여서 As/Rs 가 제공하는 URL에 client_id, redirect_uri , scope 등의 매개변수를 포함하여 전달
  2. Ex )

• 3~4 로그인 페이지 제공, ID / PW 제공
  • 클라이언트가 빌드한 인증 페이지로 이동한 사용자는 제공된 로그인 페이지에서 ID / PW로 인증.
• 5~6 Authorization Code 발급, Redirect URI로 Redirect 처리.
  • 인증 성공 - As가 client가 제공한 redirect_uri로 사용자를 던진다. + (Authorization Code 포함)
    • 이 Authorization Code는 client가 Access Token을 획득하기 위해 사용하는 임시 코드. (1분정도 수명)
• 7~8 client는 ~6까지의 결과로 받은 Authorization Code를 As에 전달하고 Access Token을 받는다.
  • 발급받은 Access Token을 저장하고, Rs의 리소스에 접근 할 때마다 Access Token을 사용한다.
    • 토큰 간의 교환은 token 엔드포인트에서 이루어진다

• 9 로그인 성공.
• 10 ~ 13 발급받은 액세스 토큰으로 리소스 접근

 

---

Authorization Code와 Implicit Grant(암묵적 승인)

 

글 출처 : https://hudi.blog/oauth-2.0/

Authorization Code를 발급하지 않고, 곧바로 Client에게 Access Token을 발급해줘도 되지 않을까? 
왜 굳이 Access Token을 획득하는 과정에 Authorization Code 발급 과정이 필요할까?

Redirect URI를 통해 Authorization Code를 발급하는 과정이 생략된다면, 
Authorization Server가 Access Token을 Client에 전달하기 위해 Redirect URI를 통해야 한다.
이때, Redirect URI를 통해 데이터를 전달할 방법은 URL 자체에 데이터를 실어 전달하는 방법밖에 존재하지 않는다.
브라우저를 통해 데이터가 곧바로 노출되는 것 이다.

하지만, Access Token은 민감한 데이터이다. 이렇게 쉽게 노출되어서는 안된다. 
이런 보안 사고를 방지 Authorization Code를 사용하는 것 이다.

Redirect URI를 프론트엔드 주소로 설정하여, Authorization Code를 프론트엔드로 전달한다.
그리고 이 Authorization Code는 프론트엔드에서 백엔드로 전달된다. 

코드를 전달받은 
백엔드는 비로소 Authorization Server의 token 엔드포인트로 요청하여 Access Token을 발급한다.

이런 과정을 거치면 Access Token이 
항상 우리의 어플리케이션과 OAuth 서비스의 백채널을 통해서만 전송되기 때문에
공격자가 Access Token을 가로챌 수 없게된다.

 

 

Implicit Grant │ 암묵적 승인 방식 - 이전에 javaScript에서 많이 썼다고 함.

위와 같은 방식 외에도 암묵적 승인 방식이 있다. 권한 부여 승인 코드 없이 바로 Access Token이 발금되는 방식이며, 만료기간을 짧게 설정하여 누출 위험을 줄일 필요가 있다고 한다. - 권장하지 않는 방식.

• 또한 Refresh Token사용이 불가능하다.
• 응답-효율이 좋지만 Access token이 URL로 전달된다는 단점이 있다.

 

Authorization Code에서는 신뢰 할 수 있는 back Channel에서 반환 받지만, Implicit Grant방식에서는 Access token이 URL에 직접 반환 (RedirectURL로 전달되는 것.)

 

 

 

 

 

⎈ 끝.

 

---

 

 

 

 

참조 : https://www.youtube.com/watch?v=aEk-7RjBKwQ

참조 : https://hudi.blog/oauth-2.0/

OAuth 2.0 개념과 동작원리

참조 : https://blog.naver.com/mds_datasecurity/222182943542

OAuth 2.0 동작 방식의 이해

참조 : https://www.youtube.com/watch?v=ZEaJsa5dwNY