꾸준히,성실하게

@AuthenticationPrincipal 어노테이션을 사용하면 JWT 토큰 정보에 필터링 된 유저정보를 Controller 에서 간단히 가져올 수 있습니다. 이번 포스팅에서 변경해볼 사항은 SecurityContextHolder (이전) -> @AuthenticationPrincipal(변경) 해보겠습니다. Spring Security 에서는 인증된 사용자 정보를 SecurityContextHolder 내부의 SecurityContext 에 Authentication 객체로 저장을 하고 이후 필요할 때 꺼내어 사용합니다. SecurityContextHolder 에 저장된 회원을 꺼내어 사용하는 방법을 알아보겠습니다. 먼저 해당 어노테이션을 몰랐을 때, 사용했던 방법은 아래와 같은 방법을 통해 auth..

사전과제로 여러 요구사항 중 권한을 부여하는 요구가 있어 정리했습니다. 이전에 프로젝트할 때 구현을 해보았을 때 권한부분에서는 순조로웠는데, 이번에는 403 에러가 계속 발생해 설정에 관한 부분을 다시 한번 학습할 수 있었습니다. 권한을 Enum 으로 지정한 클래스입니다. Enum 으로 지정한 이유는 잘못된 권한(값) 이 들어오지 않도록 하기 위해서 입니다. 3가지 권한이 있는데 여기서 실수가 있었습니다. ROLE_ 을 안붙여줘서 403 에러가 발생했습니다. 붙여야 하는 이유는 SpringSecurity 가 prefix를 자동으로 "ROLE_" 을 넣어주기 때문입니다. @Getter public enum AccountType { ROLE_LESSOR("임대인"), ROLE_REALTOR("공인중개사"),..

스프링 시큐리티의 구조 및 JWT로 구현하는 예제는 정말 많다. 정말 어려운 부분이면서 깊이가 상당한 라이브러리를 시작하기 위해서 따라해보고 첨삭을 통해 프로젝트에 필요없는 코드는 제외했다. 또한, 리프레시 토큰도 처음에는 구현했으나, 제외하고 엑세스 토큰만 구현했다. 1. 가장 기본이 되는 엑세스 토큰으로 구현하고 필요할 때, 리프레시 토큰을 사용하는 것이 옳은 방법이라고 판단했다. ( 로그인만 사용하는 단계에서 그 이상으로 구현할 때, 해당 코드에 대해 자세히 분석하지 못하고 구현하거나 그 이상으로 복잡해지면 이후 리팩토링 하는 과정이 더 힘들것이라고 생각했다 ) 2. 리프레시 토큰을 탈취당하면 엑세스 토큰을 탈취당하는 것보다 이상의 문제가 생길것이라고 판단했다. 3. 기준은 없지만, 엑세스 시간을 ..

인증 : 해당 사용자가 본인이 맞는지 확인 인가 : 인증된 사용자가 요청한 자원에 접근 가능한지 권한 확인 Principal (접근주체) : 보호받는 Resource 에 접근하는 대상 Credential (비밀번호) :Resource 에 접근하는 대상의 비밀번호 인증 -> 인증 성공 후 -> 인가 인증과 인가를 위해 principal 을 아이디로, Credential 을 비밀번호로 사용한다. 스프링 시큐리티의 구조 1. AuthenticationFilter 에서 Http 요청을 받는다. 2. 해당 부분에서는 request 로 부터 username, password 를 가지고 와서 UsernamePasswordAuthenticationToken을 생성한다. 3. 생성된 UsernamePasswordAuth..

1. 기본인증 -> 처음 애플리케이션 시작하면 콘솔에 있는 랜덤 비밀번호 사용 Id : user (고정) password : 콘솔창 확인 2. yml에 사용자 추가하기 application.yml 에 사용자 추가하기 spring: security: user: name: user1 password: 1234 roles: USER 3. UserDetailsService 서비스 빈을 추가하기 USER , ADMIN 으로 테스트하기 위해서는 yml 에 추가하는 것으로는 불가능 서비스빈을 사용해 여러명을 등록 설정추가 ( @Configuration , @Bean 사용 ) @Configuration //설정 정보를 추가해준다 public class SecurityRoleTest { @Bean // 스프링 컨테이너에..

JWT 는 당사자간의 정보를 JSON 객체로 안전하게 전송하기 위한 방법이다. 헤더 - Header 어떤 알고리즘이 사용되었는지 유형은 무엇인지 확인할 수 있다. 헤더에 있는 알고리즘으로 Signature에서 사용한다. 알고리즘은 SHA256 또는 RSA 를 대중적으로 사용한다. RSA 는 비대칭키 암호화 방식을 사용해 잠금한다. 공식홈페이지 예시로는 HS256 알고리즘을 사용하며, 유형은 JWT 라는 것을 알 수 있다. 페이로드 - Payload 민감한 정보를 담으면안된다. JWT 를 가지고 디코딩을 하면 해당 값을 모두 알 수 있기 때문이다. 클레임을 포함하고 있다 클레임이란 사용자 및 추가 데이터에 대한 설명을 의미한다. 구성된 페이로드는 Base64Url로 인코딩된다. 클레임은 3가지로 나뉜다. ..

인증 (Authentication) : 사용자가 맞는지 확인 -> 로그인 인가 (Authorization) : 권한부여 -> 자신이 작성한 글 확인 등 ( 인증 이후 ) 1. 세션기반 인증 세션 기반 인증은 서버 기반의 인증방식이다. 따라서 서버 측에서 사용자들의 정보를 기억하고 있어야 하므로 stateful 한 구조를 갖는다. 사용자들의 정보를 기억하기 위해서는 사용자의 정보를 메모리에 저장한다. 클라이언트는 쿠키저장소에 서버로부터 받은 SessionID 를 저장한다. 장점으로는, 토큰방식처럼 signiture 등등 부가적인 정보가 없기 때문에, 주고받는 데이터가 적다 단점으로는, 서버에서 직접 정보를 저장하기 때문에, 정보를 저장하는데 한계가 있다. 하드디스크나 DB에 저장하기에는 작업이 느리고, 무..

시큐리티 의존성만 추가하고 실행하면 모든 요청에 인증을 해야한다. 각 페이지마다 필요한 권한과 인증의 유무가 다른데, 확인하고 이후 설정해야한다. EX ) 인증이 필요없는 경우 : 상세페이지 화면, 게시물 조회 등 인증이 필요한 경우 : 주문, 글쓰기, 댓글 등 관리자 권한이 필요한 경우 : 상품 등록 등 의존성 추가하기 - gradle implementation 'org.springframework.boot:spring-boot-starter-security' testImplementation 'org.springframework.security:spring-security-test' 해당 의존성을 추가하면 모든 요청에 대해 인증을 요청한다. 로그인 페이지로 이동하게 되는데, 스프링에서 제공하는 아이디..

애플리케이션의 보안에서 중요한 두가지 영역은 '인증'과 '인가' 이다. 웹에서 인증이란, 해당 리소스에 대해서 작업을 수행할 수 있는 주체인지 확인하는 것이다. 예를 들어 어떤 커뮤니티에서 게시판의 글을 보는 것은 로그인을 하지 않아도 되지만, 댓글을 작성하려면 로그인을 해야한다. 댓글을 달기 위해서는 로그인이라는 인증을 거쳐야 한다. 인가는 인증 이후에 일어난다. 커뮤니티를 관리하는 관리자 페이지에 접근하는 URL을 입력했을 때, 해당 URL 은 커뮤니티의 관리자만 접근할 수 있어야 한다. 이때 접근하는 사용자가 해당 URL 에 대해서 인가된 회원인지를 검사하는 것이다. 인가된 회원이라면 URL 에 대한 권한이 있기 때문에 접근이 가능하다.