[스프링] 4. SecurityConfig에 대한 유틸 추가하기

저번 게시글까지 SecurityConfig를 만들고, 이에 대해 간단한 설정을 해두었다. 

문제는, 모든 과정이 시큐리티 필터 체인에 맞게 돌아가지 않을 수 있다. 

사진을 보면 인증정보, 즉 Authentication은 SecurityContextHolder에서 SecurityContext를 찾아, 그 속에서 Authentication을 가져와 확인하게 된다.

 

즉, 우리(서버)가 사용자(클라이언트)에게 토큰을 주었을 때, 그 토큰을 그대로 저장하는 것이 아닌, 그 토큰에서 우리가 필요한 정보를 가져와 이를 확인하는 방식이다. 

 

또한, 이 토큰은 암호화되어있는게 기본적인 약속이다(털리면 위험하니까)

 

 

그렇다면, 우리는 토큰을 검증할 때 어떻게 해야할까? 복호화 -> 필요한 정보 가져오기 -> 정보가 있는지 확인하기

3개의 과정을 거치게 된다. 

 

일련의 문자열은 어떤 경우에건 복호화시킬 수 있다. (학교 강의시간에 해보았다. 궁금해서 정보보안 시간에 암호화 알고리즘에 평문을 넣어보고, 복호화 알고리즘에 평문을 넣어보면 특이한 문자열이 나온다)

 

그렇다면, 토큰을 우리가 주었건, 남이 주었건 그걸 가져와서 복호화시켰을 때 나오는 정보에서 우리가 필요한 정보가 있는지 확인하면 되는 것이다. 

 

@Slf4j
public class SecurityUtil {

    public static Long getCurrentMemberId(){
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        if(authentication == null || authentication.getName() == null){
            throw new RuntimeException("Security Context에 인증 정보가 존재하지 않습니다.");
        }
        return Long.parseLong(authentication.getName());
    }
}

 

이러한 코드가 만들어졌다. 

어노테이션에 대해 간단히 공부를 따로 하고 코드에 대해 공부를 해보았다. 

 

일단 위의 설명대로 Authentication을 가져온다. 이렇게 복호화 했을 때, 인증이 된 적 없거나, 인증에 사용한 아이디(authentication에 name으로 저장된다)가 존재하지 않는 경우가 있을 수 있다. 

이는 토큰 자체가 없거나, 혹은 맞지 않는 토큰일 수 있다라고 생각된다. 그래서 이렇게 두 개를 묶어 예외처리를 했다. 

문제가 없다면, Long타입으로 Authentication의 name을 반환하게 했다. 

 

후에 예외에 대해 처리를 조금 하고, 더 깊은 Security, JWT 코드 구현을 해봐야 겠다.