<div id="readability-page-1" class="page"><div><h2 id="이번-주에는-무엇을-했는가">이번 주에는 무엇을 했는가?</h2>
<p>요약하자면, 이전에 만든 API 에 JWT 를 이용한 인증을 도입해보았다.</p>
<h2 id="인증과-인가의-차이에-대해-배워보았다">인증과 인가의 차이에 대해 배워보았다</h2>
<p>쉽게 말해서 인증은 '누구인지' 확인하는 행위이고 인가는 '할 수 있는지' 확인하는 행위이다. 인증은 인가로 이어질 수 있지만, 인가는 인증으로 이어지지는 않을 수 있다.</p>
<h3 id="내-블로그에-직접-정리한-글">내 블로그에 직접 정리한 글</h3>
<ul>
<li><a href="https://jake-seo-dev.tistory.com/76">인증과 인가의 차이 정리</a></li>
</ul>
<h2 id="jwt-를-배워보았다">JWT 를 배워보았다</h2>
<p>JWT 란 JSON Web Token 으로 보안이 적용된 JSON Object 를 주고받을 수 있는 표준이다.</p>
<blockquote>
<p>JWT 는 들어보기만 하고 써보는 건 처음이라 궁금해서 이것저것 찾아보았다.</p>
</blockquote>
<h3 id="내-블로그에-직접-정리한-글-1">내 블로그에 직접 정리한 글</h3>
<ul>
<li><a href="https://jake-seo-dev.tistory.com/77">JWT (JSON Web Token) 이란 무엇이며 왜 사용하는가?</a></li>
</ul>
<h3 id="jwt-를-사용하며-생기는-이슈-사항들에-대해서도-간단히-알아보았다">JWT 를 사용하며 생기는 이슈 사항들에 대해서도 간단히 알아보았다.</h3>
<ul>
<li><a href="https://velog.io/@0307kwon/JWT%EB%8A%94-%EC%96%B4%EB%94%94%EC%97%90-%EC%A0%80%EC%9E%A5%ED%95%B4%EC%95%BC%ED%95%A0%EA%B9%8C-localStorage-vs-cookie">JWT 는 어디에 저장해야 할까?</a></li>
<li><a href="https://stackoverflow.com/questions/32060478/is-a-refresh-token-really-necessary-when-using-jwt-token-authentication">Is a Refresh Token really necessary when using JWT token authentication?</a></li>
<li><a href="https://velog.io/@park2348190/JWT%EC%97%90%EC%84%9C-Refresh-Token%EC%9D%80-%EC%99%9C-%ED%95%84%EC%9A%94%ED%95%9C%EA%B0%80">JWT 에서 Refresh Token 은 왜 필요한가?</a></li>
</ul>
<h3 id="저장-위치는-어디가-좋을까">저장 위치는 어디가 좋을까?</h3>
<p>JWT 는 쿠키 혹은 로컬스토리지에 보통 저장하는데, 둘 다 보안에 취약하지만 그래도 HttpOnly 를 적용한 쿠키가 그나마 나은 옵션이라고 여겨지고 있다. 기본적으로 브라우저에 있는 정보들은 자바스크립트로 접근이 가능하기 때문에 XSS 공격에 취약하다고 여겨지고 있다.</p>
<h3 id="jwt-의-보안-이슈사항">JWT 의 보안 이슈사항</h3>
<p>JWT 의 경우 한번 탈취되면, 상당히 골치아파진다. 그렇다고 해서 매번 만료 주기를 짧게 잡으면, 사용자가 사이트를 켜놓고 딴짓을 하게 된다고 쳤을 때, 이용하는 중간 중간에 계속 로그인을 새로 해주어야 한다.</p>
<p>이 경우 토큰을 2개 발급하여, 1개는 <code>Refresh Token</code> 용도로 사용하고 1개는 일반 <code>Access Token</code> 을 만든다. <code>Access Token</code> 은 짧은 만료 주기를 갖고 계속 만료가 되는 형태가 될 것이고, <code>Refresh Token</code> 은 긴 만료주기를 갖고 계속 <code>Access Token</code> 을 업데이트 하는 전략을 사용할 수 있다.</p>
<blockquote>
<p>물론 두 토큰 모두 탈취당하면 답이 없다.</p>
</blockquote>
<h3 id="jwt-는-왜-좋을까">JWT 는 왜 좋을까?</h3>
<p>비교군으로는 세션 기반 인증이 있다.</p>
<p><strong>stateless vs stateful</strong></p>
<p>세션 기반 인증과 JWT 의 가장 커다란 차이는 아무래도 'stateless 로 구현 가능하냐' 인 것 같다. 그러나 JWT 인증도 여러가지 보안 요소를 고려하다보면 결국 실제 서비스에서는 'stateless' 는 될 수도 있고 안 될 수도 있다.</p>
<p><strong>도메인에 대한 제약이 상대적으로 적음</strong></p>
<p>MSA (Micro Service Architecture) 가 유행하며, JWT 가 기본적으로 도메인 제약이 상대적으로 적은 인증 방식이라는 것 때문에 유행하는 것도 있는 것 같다.</p>
<h2 id="코드-리뷰-사항들">코드 리뷰 사항들</h2>
<h3 id="bean-value-configuration-애노테이션-내용을-정리했다"><code>@Bean</code>, <code>@Value</code>, <code>@Configuration</code> 애노테이션 내용을 정리했다</h3>
<p><img src="https://velog.velcdn.com/images/jakeseo_me/post/42f452f5-9d17-4b61-aeb9-8ec607a09cfd/image.png"></p>
<p>2개는 이전에 정리해보았던 애노테이션이라 <code>@Value</code> 만 한번 정리해보았다. 스프링의 <code>BeanPostProcessor</code> 를 통해 실행되는지 처음 알았고 SpEL 문법 활용이 가능한 것도 처음 알게 되었다.</p>
<ul>
<li><a href="https://jake-seo-dev.tistory.com/75">https://jake-seo-dev.tistory.com/75</a></li>
</ul>
<h3 id="dto-에서의-쓸모-없는-setter-사용을-자제하자">Dto 에서의 쓸모 없는 <code>@Setter</code> 사용을 자제하자</h3>
<p><img src="https://velog.velcdn.com/images/jakeseo_me/post/5fb2e35f-e842-4f64-a22f-6cb67fcdb4c0/image.png"></p>
<p><code>Jackson</code> 라이브러리는 <code>@Setter</code> 없이도 객체 매핑을 잘 해주어서, 사실상 <code>@Setter</code> 가 필요 없었다. 필요할 때만 쓰자.</p>
<h3 id="완곡한-표현을-사용하자">완곡한 표현을 사용하자</h3>
<p><img src="https://velog.velcdn.com/images/jakeseo_me/post/882aabab-d369-4270-b6ef-307dc0033081/image.png"></p>
<p>클라이언트에게 메세지를 줄 때는 완곡한 표현을 사용하자. 최근 회사 업무에서도 많이 느끼고 있는데, 서비스 이용 중 예외가 발생하면 고객은 내가 작성한 딱딱한 예외 메세지를 받고 어떤 일이 일어났는지 파악하게 된다. 인터넷 끊김과 같은 케이스도 생각하며 예외 메세지를 조금만 더 완곡하게 표현해 더욱 포용력 있는 답을 해보자.</p>
<h3 id="메서드-추출">메서드 추출</h3>
<p><img src="https://velog.velcdn.com/images/jakeseo_me/post/cd7ee7ec-0f64-4747-bf07-b76d43d76a48/image.png"></p>
<p>의미를 가진 코드 조각은 메서드로 추출해서 가독성을 챙기자.</p>
<h3 id="validuser-대신-registereduser"><code>validUser</code> 대신 <code>registeredUser</code></h3>
<p><img src="https://velog.velcdn.com/images/jakeseo_me/post/264444a6-0acb-426a-9c99-5ac384fdce20/image.png"></p>
<p>코드의 의미는 간결하면서 명확하게 드러날수록 좋다. <code>valid</code> 는 <code>registered</code> 보다는 덜 구체적이므로 생각을 한번만 더 해보고 조금 더 구체적인 표현이 없는지 생각해보자.</p>
<h3 id="junit의-displayname-작성-시-클래스명의-디커플링을-조심하자">Junit의 <code>@DisplayName</code> 작성 시 클래스명의 디커플링을 조심하자</h3>
<p><img src="https://velog.velcdn.com/images/jakeseo_me/post/70b6e8b6-516a-4447-b0c4-6272d22128d0/image.png"></p>
<p>여기서 <code>UserLoginException</code> 이라는 예외 이름을 변경하여, 디커플링 되는 경우가 생겨버렸다. 다음부터 이런 경우를 조금만 더 생각해보자.</p>
<h3 id="내부적으로-보여지게-되는-로그-메세지는-미래의-디버깅하는-나를-배려해주는-마음으로-작성하자">내부적으로 보여지게 되는 로그 메세지는 미래의 디버깅하는 나를 배려해주는 마음으로 작성하자</h3>
<p><img src="https://velog.velcdn.com/images/jakeseo_me/post/54793ee8-bffb-49bc-a5c6-2ef030bea785/image.png"></p></div></div>

jakeseo-javascript.js 🔨

이번 주에는 무엇을 했는가?
요약하자면, 이전에 만든 API 에 JWT 를 이용한 인증을 도입해보았다.
인증과 인가의 차이에 대해 배워보았다
쉽게 말해서 인증은 '누구인지' 확인하는 행위이고 인가는 '할 수 있는지' 확인하는 행위이다. 인증은 인가로 이어질 수 있지만, 인가는 인증으로 이어지지는 않을 수 있다.
내 블로그에 직접 정리한 글
인증과 인가의 차이 정리
JWT 를 배워보았다
JWT 란 JSON Web Token 으로 보안이 적용된 JSON Object 를 주고받을 수 있는 표준이다.
JWT 는 들어보기만 하고 써보는 건 처음이라 궁금해서 이것저것 찾아보았다.
내 블로그에 직접 정리한 글
JWT (JSON Web Token) 이란 무엇이며 왜 사용하는가?
JWT 를 사용하며 생기는 이슈 사항들에 대해서도 간단히 알아보았다.
JWT 는 어디에 저장해야 할까?
Is a Refresh Token really necessary when using JWT token authentication?
JWT 에서 Refresh Token 은 왜 필요한가?
저장 위치는 어디가 좋을까?
JWT 는 쿠키 혹은 로컬스토리지에 보통 저장하는데, 둘 다 보안에 취약하지만 그래도 HttpOnly 를 적용한 쿠키가 그나마 나은 옵션이라고 여겨지고 있다. 기본적으로 브라우저에 있는 정보들은 자바스크립트로 접근이 가능하기 때문에 XSS 공격에 취약하다고 여겨지고 있다.
JWT 의 보안 이슈사항
JWT 의 경우 한번 탈취되면, 상당히 골치아파진다. 그렇다고 해서 매번 만료 주기를 짧게 잡으면, 사용자가 사이트를 켜놓고 딴짓을 하게 된다고 쳤을 때, 이용하는 중간 중간에 계속 로그인을 새로 해주어야 한다.
이 경우 토큰을 2개 발급하여, 1개는 Refresh Token 용도로 사용하고 1개는 일반 Access Token 을 만든다. Access Token 은 짧은 만료 주기를 갖고 계속 만료가 되는 형태가 될 것이고, Refresh Token 은 긴 만료주기를 갖고 계속 Access Token 을 업데이트 하는 전략을 사용할 수 있다.
물론 두 토큰 모두 탈취당하면 답이 없다.
JWT 는 왜 좋을까?
비교군으로는 세션 기반 인증이 있다.
stateless vs stateful
세션 기반 인증과 JWT 의 가장 커다란 차이는 아무래도 'stateless 로 구현 가능하냐' 인 것 같다. 그러나 JWT 인증도 여러가지 보안 요소를 고려하다보면 결국 실제 서비스에서는 'stateless' 는 될 수도 있고 안 될 수도 있다.
도메인에 대한 제약이 상대적으로 적음
MSA (Micro Service Architecture) 가 유행하며, JWT 가 기본적으로 도메인 제약이 상대적으로 적은 인증 방식이라는 것 때문에 유행하는 것도 있는 것 같다.
코드 리뷰 사항들
@Bean, @Value, @Configuration 애노테이션 내용을 정리했다
2개는 이전에 정리해보았던 애노테이션이라 @Value 만 한번 정리해보았다. 스프링의 BeanPostProcessor 를 통해 실행되는지 처음 알았고 SpEL 문법 활용이 가능한 것도 처음 알게 되었다.
https://jake-seo-dev.tistory.com/75
Dto 에서의 쓸모 없는 @Setter 사용을 자제하자
Jackson 라이브러리는 @Setter 없이도 객체 매핑을 잘 해주어서, 사실상 @Setter 가 필요 없었다. 필요할 때만 쓰자.
완곡한 표현을 사용하자
클라이언트에게 메세지를 줄 때는 완곡한 표현을 사용하자. 최근 회사 업무에서도 많이 느끼고 있는데, 서비스 이용 중 예외가 발생하면 고객은 내가 작성한 딱딱한 예외 메세지를 받고 어떤 일이 일어났는지 파악하게 된다. 인터넷 끊김과 같은 케이스도 생각하며 예외 메세지를 조금만 더 완곡하게 표현해 더욱 포용력 있는 답을 해보자.
메서드 추출
의미를 가진 코드 조각은 메서드로 추출해서 가독성을 챙기자.
validUser 대신 registeredUser
코드의 의미는 간결하면서 명확하게 드러날수록 좋다. valid 는 registered 보다는 덜 구체적이므로 생각을 한번만 더 해보고 조금 더 구체적인 표현이 없는지 생각해보자.
Junit의 @DisplayName 작성 시 클래스명의 디커플링을 조심하자
여기서 UserLoginException 이라는 예외 이름을 변경하여, 디커플링 되는 경우가 생겨버렸다. 다음부터 이런 경우를 조금만 더 생각해보자.
내부적으로 보여지게 되는 로그 메세지는 미래의 디버깅하는 나를 배려해주는 마음으로 작성하자

코드숨 스프링 편 6주차 회고: 로그인

댓글