[도전 기술!] 토큰 전략, 권한 인증

🚀 토큰을 사용한 이유?

가장 큰 이유는 HTTP의 특징 중 Connectionless 와 Stateless 때문입니다.

HTTP 프로토콜은 한번의 요청 - 응답 사이클이 완료되면 연결을 종료하기 때문에, 동일한 클라이언트가 여러번 요청을 해오더라도 서버는 해당 클라이언트에 대한 권한을 인지할 수 없습니다.

클라이언트의 상태를 유지하기 위한 방법으로는 대표적으로 세션과 쿠키 방식이 있습니다.

Cookie 방식 : 개별 Client 상태 정보를 HTTP Request / Response Header에 담아 전달하는 Infomation / Data를 이야기 합니다.

 

<출처 :&nbsp; https://ledgku.tistory.com/72 >

Cookie는 치명적인 단점이 있는데, 그것은 바로 보안 취약점 입니다.

Cookie 방식은 Client 상태 정보를 Client에 저장하고, HTTP Request / Response Header에 담아 전달하기 때문에 해킹 및 스니핑 공격에 의한 변조와 외부 노출에 취약한 단점이 있습니다.

위 사진처럼 암호화 되지 않은 Cookie는 통신 간 정보가 모두 노출됩니다.

Session 방식 : 개별 Client 상태 정보를 Server에 저장하는 기술 입니다.

Server는 개별 Client Session 식별하기 위해 "Session ID"를 부여하고, 이것은 "Session Cookie"를 이용하여 Client와 Server 간에 주고 받는 형식으로 동작합니다.

Session방식은 Client 상태 정보를 Server에 저장하기 때문에 Cookie에 비해 보안상 안전하다는 장점이 있으나, 이것 역시 보안상 취약점이 있는데, 공격자가 정상적인 사용자의 Session ID 정보를 탈취한다면 정상 사용자로 위장 접근이 가능한 HTTP Session Hijecking 공격이 가능하다는 취약점이 있고, Session 저장소를 Server에서 관리하기 때문에 이용자가 많아지면 많아질수록 Server에 걸리는 부하가 증가한다는 단점이 있습니다.

위의 두가지 방식이 대표적인 인증 방식이나, 열거한 단점들을 고려하여 저희는 JWT(Json Web Token)라는 방식을 채택하여 인증을 구현 해 보았습니다.

토큰 기반 인증시스템은 유저의 인증 정보를 서버나 세션에 담아두지 않습니다. 클라이언트는 API 요청할때마다 토큰을 HTTP Authorization header에 인증 정보를 담아 서버에게 보냅니다. 서버는 이 토큰을 통하여 클라이언트들을 식별할 수 있습니다.

JWT Token 방식은 크게 3가지 요소로 구성이 됩니다.

• Header : 3가지 요소를 암호화할 알고리즘 등의 Option Value
• Payload : User의 고유 ID 등 인증에 필요한 정보
• Verify Signatuer : Header, Paload와 Secret Key가 더해져 암호화

저희는 암호화 알고리즘으로 HMAC SHA256을 사용하였습니다.

여기서 HMAC은 메시지 인증 코드를 해쉬 함수를 이용하여 암호화 하는 방식이고, SHA256은 길이가 256bit 인 Message Disast를 64번의 Round를돌려 일방향(복호화 불가 방식)으로 암호화 하는 방식으로, 안전하다고 판단되어 이 암호화 방식을 선택하게 되었습니다.

또한, 서버의 부담이 감소할뿐만 아니라, 여러 플랫폼 및 도메인에서 적용가능 하다는 장점이 있습니다. 이러한 이유로, 대표적인 토큰 기반 인증 시스템인 JWT을 사용하였습니다.

 

🚀 엑세스토큰과 리프레시토큰 전략

 

먼저 Access Token은 Client가 Server에 인증을 위해 사용되는 JSON Web Token입니다.

보안에서는 100% 안전은 없다라는 말이 있습니다. JWT 역시 100% 보안에 안전할 수는 없습니다.

악의적인 이용자가 Access Token을 탈취 했다면 Session 방식에서 Session ID를 탈취한 것과 같이 특정 이용자에 권한으로 Server에 접근할 수 있다는 위험성이 있습니다. 이러한 문제로 인해 저희는 아래 그림과 같이 Access Token 유효 시간을 5분으로 주었습니다.

    //엑세스 토큰 유효시간 5분
    public static Long ACCESS_TOKEN_VALID_TIME =  5 * 60 * 1000L;

    public static String ACCESS_TOKEN_NAME = "ACCESS TOKEN";

    public static String REFRESH_TOKEN_NAME = "REFRESH TOKEN";

    public JwtUtil(String secret) {
        key = Keys.hmacShaKeyFor(secret.getBytes());
    }

이렇게 Access Token에 시간을 5분으로만 주었다면 선량한 이용자들은 5분이 지나면 다시 Login을 해야 하는 불편함이 생기게 됩니다. 이러한 문제를 극복하기 위해서 저희는 Refrash Token 기법을 추가로 사용하였습니다.

//리프레시 토큰 유효시간 24시간(ms단위)
    public static Long REFRESH_TOKEN_VALID_TIME = 1440 * 60 * 1000L;

Refrash Token의 경우 유효 기간을 24시간으로 주어 선량한 이용자가 지속적인 Login을 통해 불편함이 생기지 않도록 구현을 하였습니다. 또한, Refrash Token 역시 악의적인 이용자에게 탈취 당할 시 보안 사고로 이어질 수 있기 때문에 이 정보를 외부에 노출 시키지 않기 위해 Data Base에 저장하도록 설계 하였습니다.

 

반응형

 

@Transactional
    public DefaultRes<UserSignInResponseDto> signIn(UserSignInRequestDto requestDto){

        Optional<String> optionalEmail = userRepository.findByEmail(requestDto.getEmail());

        return optionalEmail.map(email ->{

            Optional<User> optionalUser = userRepository.findByUser(email, requestDto.getPassword());

            return optionalUser.map(user -> {
                String accessToken = JwtUtil.createAccessToken(user.getId(), user.getGrade());
                String refreshToken = JwtUtil.createRefreshToken(user.getId(), user.getGrade());
                user.setRefreshToken(refreshToken);                                                 // Dirty Checking을 이용한 Data Base 값 저장

                return DefaultRes.response(HttpStatus.OK.value(),"성공", new UserSignInResponseDto(accessToken,refreshToken, user.getId(), user.getGrade()));

            }).orElseGet(()-> DefaultRes.response(HttpStatus.OK.value(), "비밀번호불일치"));

        }).orElseGet(()->DefaultRes.response(HttpStatus.OK.value(), "아이디불일치"));

    }

 

 

🚀 서버와 클라이언트간의 통신

 

 

📌 권한 처리

클라이언트 요청에 대한 권한 처리는 스프링 인터셉터를 활용하여 구현하였습니다.

Client가 Request를 보내게 되면 Dispatcher Servlet에서 Request에 해당하는 Controller로 가기 전에 해당 내용을 Interceptor가 가로채게 합니다.

이를 통해 저희가 구현한 User Grade (Admin, End User, Black User)를 확인하고, 해당 Grade에 맞는 행동만을 할 수 있게 구현을 했습니다.

}else if(tokenName.equals(JwtUtil.REFRESH_TOKEN_NAME)){
            Long userPk = claims.get("user_pk", Long.class);
            Boolean check = sessionService.refreshTokenCheck(userPk, jwtToken);
            if(check){
                String accessToken;
                if(userGrade.equals(UserGrade.ADMIN)){
                    accessToken = JwtUtil.createAccessToken(userPk, UserGrade.ADMIN);
                }else{
                    accessToken = JwtUtil.createAccessToken(userPk, UserGrade.USER);
                }

위와 같이 먼저 저희는 Login한 이용자가 정상적인 Token을 가지고 있는지를 확인한 뒤 그 이용자 회원정보의 Grade 값을 판단하게 만들었습니다.

즉, 저희는 Interceptor를 통해 이용자의 Token Value를 판단하고, User Grade을 판단하여 거기에 맞는 권한을 가지고, 저희가 구현한 Service를 이용할 수 있도록 구현하였습니다.