[우리집 가족 커뮤니티 웹 서비스 프로젝트] 기술 정리 - Spring Security 초기 구성

우리 가족의 커뮤니티 웹 서비스를 만들기 위해 먼저 Server 작업을 하고 있는 것이에요.

코딩을 하면서 내용을 정리해서 나중에 주니 하랑도 확인하고, 여기 오신 여러분들과도 공유하고 싶은 것이에요!

그럼 시작해 보겠습니다!

 

 

해당 프로젝트에 대한 Source Code는 '주니하랑 Git Hub'에서 확인하실 수 있습니다.

 

 

---

 

🗂 목차(INDEX)
       1.  초기구성

       2. Spring Security 초기 구성

       3. Interceptor 설정

.      4. 초기 Domain 설정

 

 

 

 

---

 

 

🚀 Package Tree

 

 

 

🚀 CORS Filter

 

 

먼저 이 코드는 CORS Filter를 구현한 뒤 Bean으로 등록하기 위해 작성한 것이에요. 이 방법은 Spring MVC가 아닌 Srping WEB에만 의존하거나, Security 설정 Level에서 CORS를 필수적으로 확인할 때 유용하기에 사용한 것이에요.

13번째 줄에 대해 이야기 하자면 @Order는 Spring Bean의 순서를 정할 때 사용하는 것이에요.
Default Option은 Ordered.LOWEST_PRECEDENCE이고, collection에 componenet를 Spring 4.0에서부터 주입할 수 있게 되면서 이 어노테이션을 통해 순서를 정하는데, 사용하게 된 것이에요.

@Order에는 상수값을 통해 순서를 정할 수 있고, 주니하랑이 준 Ordered.HIGHEST_PRECEDENCE의 실제 상수값은 -2147483648으로 제일 먼저 실행하게 하겠다는 의미인 것이에요.

@Order에 대해서는 이 곳에 자세히 설명을 달아 놓도록 하겠습니다.

doFilterInternal()를 override(재구성)하고, 매개변수 중 하나인 response 안에 SetHeader에 대해 설정을 하는 것이에요. 이렇게 한 이유는 바로 Filter를 등록하여 CORS에 대한 처리를 할 수 있게 하기 위함입니다.

위의 원리는 실제 요청하기 전에 예비요청(Preflight Request)를 통해 허용 가능한 Domain, Method 등을 응답하고, 이를 통해 통신할 수 있도록 하는 것이에요.

19번째 줄은 Request에 Cookie, authorization Header들 또는 TLS Client 인증서 등을 담아 보내는 것을 허용한다는 것이에요. 이 경우 Access-Control-Allow-Origin, *과 같이 정규식을 사용할 수 없기 때문에 위와 같이 Origin값을 직접 명시적으로 지정한 것이에요.

Request의 Orgin Header를 동적으로 받아 설정하기 때문에 '*' 과 같은 설정이랍니다.

 

이렇게 구현하면 차후 ajax를 아래 처럼 주면 되는 것이에요.

$.ajax({
	url: 'http://hongga-community.com/hello',
    data: {
    	param_1 : '111'
        param_2 : '222'
    },
    type: 'GET'
    dataType : 'json',
    xhrFields: {
    	withCredentials: true
    },
    success: function(data) {
    	console.log(data);
    },
    error : function(e) {
    	console.log(e);
    }
});

 

위의 xhrFilds에 withCredentials true는 XMLHttpRequest를 생성할 때, Cookie, authorization Header들 TLS 인증서를 포함하게 된답니다.

 

 

🚀 JwtUtil

    🔽 Field Variable

먼저 주니하랑은 JAVA에서 암호화 관련 Key를 제공하는 java.security.Key를 static 변수로 만들어 준 것이에요.

그 다음에는 jwt에 대한 Log를 남기기 위해 slf4j를 사용한 부분인 것이에요.

Refresh Token의 유효기간은 2주를 줘서 이용자들의 편의와 보안을 신경 쓴것이에요.
Access Token은 1시간을 주었답니다.

그 다음 30번째 줄에 Method Body는 이 내용을 위해 준 것이에요.

그 전에 Hash Function을 잘 모르신다면 이 곳을 참고 하시기 바라는 것이에요.

HMAC-SHA 알고리즘과 문자열 secret key 또는 인코딩된 byte array를 사용해서 JWT에 서명하는 경우 signWith 메소드 인수로 사용할 SecretKey 인스턴스로 변환해야 하는 것이에요.

• 인코딩된 byte array:

SecretKey key = Keys.hmacShaKeyFor(encodedKeyBytes);

• Base64 인코됭된 문자열

SecretKey key = Keys.hmacShaKeyFor(Decoders.BASE64.decode(secretString));

• Base64URL 인코딩된 문자열

SecretKey key = keys.hmacShakeyFor(Decoders.BASE64URL.decode(scretString));

• 인코딩 안된 문자열(예 password 문자열)

SecretKey key = Keys.hmacShaKeyFor(secretString.getBytes(StandardCharsets.UTF_8));

secretString.getBytes()시에는 항상 캐릭터셋을 지정해야 하는 것이에요.

그리고 식별할수 있는 문자열 pasword는 가능한 피해야 하는 것이에요. 가능하면 안전한 랜덤키를 생성해서 사용하는것이 좋다고 합니다.

 

 

    🔽  Method(createAccessToken / createRefreshToken / getClaim)

이 친구는 매개 변수(파라미터)로 앞으로 생성하게 될 Member Entity의 @Id값, DB로 말하자면 PK값이 될 memberId와 member의 등급을 확인하게 될 memberGrade를 받아서 처리하게 됩니다.

이렇게 한 이유는 JWT를 사용하는 궁극적인 이유는 이용자에 권한을 확인해서 우리가 서비스 하고자 하는 서비스를 이용하기에 적합한지를 확인하는 것도 있기 때문에 회원 등급 값을 받고 있는 것이에요.

JWT의 만료 및 발급 시간 설정 등을 위해 Date()를 하나 생성을 해준 뒤 Jwts의 Builder Pattern을 통해 설정을 하는 것이에요.

일단 간략하게 JWT란 무엇인지 알아볼까 해요!

'Json Web Token'의 약자 이며, 'Json format'을 이용 웹에서 사용할 수 있는 엑세스 토큰을 다루는 표준인 것이에요. JWT를 이용 적절한 의미를 가진 토큰을 만들 수 있는 것이에요.

JWT는 크게 3가지 부분으로 나누어져 있는 것이에요.

Part	Description
Header	- 어떤 타입의 데이터인지. - 어떤 알고리즘을 사용할지.
Payload(Claims)	- 실제 어떤 데이터가 담겨 있는지(암호화가 안 되어 있어 웹으로 노출하면 안되는 데이터를 담아서는 안됨.) - 가능한 많은 데이터를 담지 않는 것이 좋다. - Production으로 사용 할 시에는 토큰이 언제까지 유효한지 담는 것이 좋음.
Signature	- 데이터와 토큰이 위/변조 되지 않았음 증명. - 데이터를 일정하게 해싱하고 해싱한 데이터를 암호화 해서 데이터가 위/변조 되지 않음 증명. - HMAC-SHAXXX 사용.   (해당 알고리즘 사용 위해 비밀키 생성을 하는데, 비밀키는 반드시 노출이 되지 않도록 조심!)

위의 Json 데이터를 그냥 보내는 것이 아니라 Base64 URL Encoding 해줘야 하는 것이에요.

Cliaims 즉, JWT의 Payload에 회원 Table의 PK값이 될 memberId와 회원 등급인 memberGrade값을 넣어주고, Access Token 이름값을 같이 넣어 주는 것이에요.

43번째 줄에는 JWT 발급 시각의 대한 정보를 담기 위해 현재 Server의 시간을 가져올 인스턴스를 넣어준 것이에요.

45번째 줄에는 JWT 만료 시각의 대한 정보를 담기 위해 현재 Server 시간과 발급 시각을 넣어주고, ACCESS_VALID_TIME 값(60분)을 넣어서 now.getTime() 즉, 발급 시각의 시간을 가져와서 ACCESS_VALID_TIME, 60분을 더해서 새로운 Date 객체를 만들고, 그 값을 만료 시간으로 설정한 것이에요.

46번째 줄은 복호화할 때 사용하는 Signature를 설정한 것이에요. Signature는 Header의 인코딩 값과 Payload의 인코딩 값을 합친 뒤, 서버만이 알고 있는 비밀키로 해쉬를 하여 생성하는 것이에요.
signWith api는 해싱할 알고리즘과 비밀키를 필요로합니다. key가 비밀키를 반환하는 것이랍니다!

 

반응형

 

Refresh Token 발급도 위 Access Token과 비슷하게 생성하지만, 만료 시간을 2주로 설정한 것이에요.
그래야 이용자의 힘든 Login 작업을 조금은 편리하게 만들어 줄 수 있기 때문이에요.

보안을 강화하면 편리성이 떨어지고, 편리성을 올린다면 보안이 떨어지는 것이에요.
이 딜레마를 극복하기 위해 저희 가족 커뮤니티에서는 이 정도 값이 적절하겠다고 판단한 것이에요.

 

 

이번 Method는 Token의 만료 일시와 복호화를 확인 즉! 유효성을 검사하기 위한 Method인 것이에요.

위에서 생성된 Token을 이용자는 받아서 Server에 전달을 할 것이고, Server는 해당 Method를 통해 유효성을 검사할 것이에요.

Exception이 터질 수 있으니 Try - catch문으로 감싸고, JWT는 String 즉, 문자열로 이뤄져 있기 때문에 이것을 사용하기 위해 Jwts.paser를 통해 Parsing을 하고, Token을 만들 때, 사용했던 key를 가지고, setter를 통해 값을 넣어줘야 하는 것이에요. 들어온 Token의 SigningKey 즉, Data와 Token 등이 위 / 변조 되었는지를 확인하고, parseClaimsJws를 통해 Token을 Jws로 Parsing하는 것이에요.
마지막으로 getBody()를 이용해서 앞에서 Token에 저장했던 Data들이 담긴 Claims (Payload)를 얻어온 것을 반환하도록 한 것이에요.

그런데? 문제가 있다면? null을 반환하도록 하였습니다!

 

위와 관련된 JWT에 관련한 내용은 이 곳에 정리 해 두었어요! 참고로 이 글은 팀 프로젝트를 할 때, 주니하랑이 정리한 자료 입니다.