Back-End

의존성 추가 dependencies { implementation 'org.springframework.boot:spring-boot-starter-security' } gradle 파일에 위의 스프링 시큐리티 의존성을 추가한 후에 별다른 설정 없이 서버를 실행한 후에 로컬 환경에서 사이트에 접속해보겠다. 접속해보면 로그인 페이지나 기능을 구현한 적이 없어도 스프링 시큐리티에서 기본적으로 제공해주는 인증 페이지로 접속되는걸 확인할 수 있다. 기본 인증은 Username에 user, Password에 위의 비밀번호를 복사해서 로그인 할 수 있다. 인증을 하기 전까지는 어떤 요청을 보내더라도 위의 페이지가 뜨게 되고 인증된 후에야 응답을 받을 수 있게 된다. 시큐리티의 기본적인 인증 방식은 위의 사진에서 알..

OAuth 2.0 인증 컴포넌트 Resource Owner 사용하고자 하는 리소스의 주인으로 웹 애플리케이션의 실제 사용자라고 생각하면 편하다. 구글 로그인 인증을 통해 사용자가 자신의 구글 계정으로 자신의 리소스를 사용하는 것이기 때문에 Resource Owner라고 부른다. Client 써드 파티 애플리케이션을 사용하지 않는 기존의 웹 애플리케이션에서 클라이언트는 사용자에 해당했지만 OAuth 2.0에서의 클라이언트는 웹 애플리케이션에 해당한다. 클라이언트는 서비스를 이용하는 쪽이고 서버는 제공하는 쪽인데 써드 파티 애플리케이션의 서비스를 제공받는 쪽은 웹 애플리케이션에 해당하기 때문이다. Resource Server 클라이언트의 요청을 수락하고 Resource Owner의 Resource를 제공하는..

OAuth 2.0 애플리케이션에서 사용자의 인증을 직접 처리하지 않고 신뢰할 수 있는 써드 파티 애플리케이션이 대신 처리하게 한 후에 해당 써드 파티 애플리케이션의 서비스까지 사용할 수 있는 방식이다. 간단하게 말하자면 요새 자주 사용되는 구글/카카오/네이버 등을 이용한 로그인 방식이다. 기존 서버에서 인증을 하고 외부 애플리케이션의 서비스를 이용하려면 외부 애플리케이션에서도 인증을 받아야 해서 두 번의 인증 과정이 필요하지만 이 방식을 사용하면 한 번의 인증만으로도 가능해진다. 인증 방식 OAuth 2.0를 사용하지 않는 기존의 로그인 방식은 클라이언트 요청 → 웹 서버 인증 → 외부 애플리케이션 서버 인증 순서로 진행되었다면 OAuth 2.0를 사용하게 되면 클라이언트 요청 → 웹 서버가 써드 파티 ..

이전에 폼 로그인 방식의 로그인/로그아웃을 구현하면서 간단하게 구조를 분석해 보았지만 시큐리티를 배우는 과정에서 좀 더 정확하게 배우고 넘어가야 할거 같아서 공식문서를 참고하며 구조를 처음부터 정확하게 분석해 보겠다. 전체적인 흐름 위의 이미지는 공식문서에서 제공해 주는 클라이언트의 요청부터 스프링 시큐리티의 필터가 처리되는 과정이다. ServletFilterChain ServletFilter DelegatingFilterProxy FilterChainProxy SecurityFilterChain SecurityFilter (ExceptionTranslationFilter, etc...) 이미지에 나타난 구조를 계층으로 표현하면 위와 같다. 코드로 살펴보기 전에 위의 과정을 글로 간단하게 정리해보겠다. ..

JWT (JSON Web Token)는 이름 그대로 JSON 포맷을 사용하여 데이터를 안전하고 간결하게 전송하는 표준 인증 방식이다. JSON 포맷의 토큰 정보를 인코딩 하고, 인코딩 된 토큰 정보를 비밀키로 서명한 메시지를 Web Token으로 인증 과정에 사용한다. JWT의 종류 Access Token 사용자의 이메일, 연락처, 사진 등과 같은 보호된 정보에 접근할 수 있는 권한 부여에 사용된다. 클라이언트가 처음 인증을 받으면 Access Token과 Refresh Token을 모두 받지만 실제 권한을 얻는데 사용되는 토큰은 Access Token이다. 사실상 권한을 부여 받을 때는 해당 토큰만 있어도 상관 없지만 해당 토큰을 탈취 당하는 경우에는 탈취한 쪽에서도 해당 토큰을 사용해 권한을 얻을 수..

HTTP 프로토콜의 비상태성 특성의 단점을 해결하기 위해 기존에는 세션을 사용하여 상태를 유지하는 방법을 사용했다. 세션 기반 자격 증명 세션 기반 자격 증명 방식은 서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장한 후에 클라이언트 측에서 요청을 하면 세션 저장소의 세션과 사용자가 제공하는 정보가 일치하는지 확인한다. 즉, 인증된 사용자의 정보를 서버 측에서 관리하고 클라이언트 쪽은 세션 ID만 사용하여 상대적으로 적은 네트워트 트래픽을 사용한다. 서버 측에서 세션 정보를 관리하여 보안성 측면에서도 유리하다고 볼 수 있지만 서버의 확장성 면에서 세션 불일치 문제가 발생할 수도 있고 세션의 데이터가 많아질수록 서버의 부담이 가중된다. CSR 방식보다는 SSR 방식에 적합한 방식이다. 토큰..

hasRole(Stirng role) 현재 보안 주체가 지정된 역할을 갖고 있는지 여부 확인 파라미터로 넘긴 role이 ROLE_로 시작하지 않으면 추가 DefaultWebSecurityExpressionHandler의 defaultRolePrefix를 수정하여 커스텀 할 수 있다. hasAnyRole(String… roles) 지정한 역할 중 하나라도 갖고 있는지 여부 확인 hasAuthority(String authority) 지정한 권한을 갖고 있는지 여부 확인 hasAnyAuthority(String… authorities) 지정한 권한 중 하나라도 갖고 있는지 여부 확인 principal 현재 사용자를 나타내는 principal 객체에 직접 접근 가능 authentication encurityC..

인증 처리 흐름 인증 방식은 여러 종류가 있지만 우선은 UsernamePasswordAuthenticationFilter에 대해 살펴보겠다. 1. 사용자의 로그인 요청 사용자가 로그인을 위해 Credential(로그인 정보)를 서버에 전달한다. 2. Authentication 객체 생성 및 전달 UsernamePasswordAuthenticationToken authRequest = UsernamePasswordAuthenticationToken.unauthenticated(username, password); UsernamePasswordAuthenticationFilter는 사용자 요청을 전달 받아 Authentication 인터페이스의 구현체인 AuthenticationToken을 생성하여 해당 객..