그림의 JWT 구조 예시에서 보이듯 JWT 헤더는 JSON 형식으로 인코딩되며, 암호화 알고리즘과 토큰 타입을 지정한다.
"alg"는 암호화 알고리즘을 지정하며, 대표적으로 HS256(HMAC SHA-256), RS256(RSASHA-256) 등이 있다.
"typ"는 토큰 타입을 지정하며, JWT인 경우 "JWT"를 사용한다.
두 번째 부분은 페이로드(Payload)로, 사용자 정보와 같은 클레임(Claim)이 포함된다.
JWT 토큰에 담겨 있는 정보를 의미한다.
사용자 ID, 권한, 만료 시간 등을 포함할 수 있다.
그림의 JWT 구조 예시에서 보이듯 JWT 페이로드는 JSON 형식으로 인코딩되며, 토큰에 포함할 클레임(Claim) 정보를 지정한다.
"sub"는 토큰의 주체(Subject)를 지정하며, 일반적으로 사용자의 ID나 이메일 주소를 사용한다.
"name"은 토큰의 주체의 이름을 지정한다.
"iat"는 토큰 발급 시간을 지정한다.
세 번째 부분은 서명(Signature)으로, 이전 두 부분을 기반으로 생성되며, 서버에서 검증할 수 있도록 디지털 서명이 포함된다.
JWT 토큰의 무결성을 검증하기 위한 서명이다.
비밀키를 사용하여 헤더와 페이로드를 지정된 암호화 알고리즘으로 서명하고, 이를 서명 부분에 추가한다.
서명을 통해 jwt의 무결성(Integrity)과 인증(Authentication)을 보장할 수 있다.
장단점
장점
JWT는 토큰 기반 인증 방식으로, 서버에서 사용자 인증 정보를 저장하지 않아도 된다.
이로 인해 서버 부하를 줄일 수 있다.
클라이언트와 서버 간의 상태를 저장하지 않기 때문에 Stateless한 구조를 가진다.
JWT는 표준화된 형식으로, 인증 정보를 전달하기 용이하다.
Base64 URL 인코딩된 문자열로 구성되어 있기 때문에 url에 포함하여 사용하기 유용하다.
JWT는 서명을 통해 무결성을 검증하기 때문에, 변조된 토큰이 발견되면 유효하지 않은 것으로 간주한다.
개인정보와 같은 민감한 정보를 포함시킬 수 없기 때문에, 보안성이 높다.
단점
JWT는 토큰이 클라이언트에게 노출될 경우 보안 위험성이 존재한다.
이를 방지하기 위해 HTTPS와 같은 보안 프로토콜을 사용하는 것이 좋다.
JWT 토큰의 정보가 해독될 경우, 사용자 정보가 노출될 수 있다.
JWT 토큰에는 만료 기간이 포함되어 있지만, 토큰이 한 번 발급되면 만료 기간 전에는 취소할 수 없다.
토큰을 분실하거나 탈취당한 경우 보안상 취약하다.
jwt 토큰의 길이가 상대적으로 길어 URL 길이 제한이 있는 경우 사용하기 어렵다.
JWT 토큰의 만료 기간이 경과하면, 사용자는 다시 인증 과정을 거쳐야 한다.
이를 간단히 처리하기 위해 리프래시(Refresh) 토큰을 사용할 수 있다.
리프래시 토큰은 기존 jwt 토큰의 만료 기간이 경과하면 발급되는 새로운 토큰으로, 만료 기간이 더 길게 설정된다.
이를 통해 사용자는 일정 기간 동안 인증을 유지할 수 있다.
세션(Session) 방식 vs. JWT(Json Web Token) 방식 세션(Session) 방식과 JWT(JSON Web Token) 방식은 모두 웹 애플리케이션에서 사용자 인증 및 인가에 사용되는 방식이다. 각 방식에는 장단점이 있으며, JWT 방식을 사용할 때의 장점은 다음과 같다: 장점 - 상태를 저장하지 않는다: JWT는 토큰 기반의 인증 방식으로, 서버에서 세션 정보를 저장할 필요가 없다. 토큰은 클라이언트에 저장되고 필요할 때마다 서버로 전송된다. 이는 서버에서 세션 상태를 유지할 필요가 없으므로 확장성이 좋아진다. 세션 방식은 서버에서 세션 정보를 저장하고 관리해야 하므로 서버에 부하가 생길 수 있다.
- 클라이언트와 서버의 독립성: JWT는 토큰에 필요한 모든 정보를 포함하므로 서버의 인증이나 인가에 대한 의존도가 줄어든다. 이는 서로 다른 도메인 간에 인증 및 인가를 공유하는 경우 유용하다. 세션 방식은 일반적으로 도메인 간 공유가 어렵다.
- 확장성과 분산 시스템 지원: JWT는 분산 시스템에서 사용하기에 적합하다. 서버 간에 토큰을 공유하거나 검증할 수 있으며, 서비스를 수평으로 확장하는 데 용이하다. 세션 방식은 일반적으로 세션 정보를 중앙 집중식 스토리지에 저장하므로 분산 시스템에서의 확장성이 낮을 수 있다.
- 권한 부여 및 정보 전달: JWT에는 토큰 자체에 사용자 권한이 포함될 수 있으므로, 토큰 검증을 통해 권한을 확인하는 데 유용하다. 또한, JWT에 추가 정보를 포함시켜 클레임(Claim)을 만들 수 있다. 이는 클라이언트와 서버 간에 추가 데이터를 전달하는 데 사용될 수 있다.
세션 방식과 JWT 방식의 각각의 장단점을 살펴본다:
세션 방식의 장점: - 서버에서 세션 상태를 직접 관리할 수 있으므로 보안 측면에서 더 안전하다. - 세션을 적극적으로 제어할 수 있으며, 로그아웃이나 세션 만료와 같은 동작을 쉽게 구현할 수 있다.
세션 방식의 단점: - 서버에 세션 정보를 저장하고 관리해야 하므로 서버 부하가 발생할 수 있다. - 세션 정보를 서버에 저장하기 때문에 확장성이 낮을 수 있다. - 도메인 간 공유가 어렵다.
JWT 방식의 장점: - 상태를 저장하지 않으므로 서버 부하가 줄어들고 확장성이 좋아진다. - 클라이언트와 서버의 독립성이 높아져 다양한 도메인 간 공유가 가능하다. - 분산 시스템에서 확장성이 좋고 서비스 수평 확장에 용이합니다.토큰에 권한 정보를 포함할 수 있고, 클레임을 통해 추가 정보를 전달할 수 있다.
JWT 방식의 단점: - 토큰의 크기가 커질 수 있으므로 트래픽이 많은 상황에서는 약간의 오버헤드가 발생할 수 있다. - 토큰 자체에 정보가 포함되어 있기 때문에 토큰을 유출하면 해당 정보가 노출될 수 있다. 따라서 토큰의 안전한 보관과 전송이 중요하다.
요약하면, JWT 방식은 상태를 저장하지 않고 클라이언트에 토큰을 전달하는 토큰 기반의 인증 방식이다. 이를 통해 확장성과 독립성을 향상시킬 수 있으며, 분산 시스템에서 효과적으로 작동할 수 있다. 세션 방식은 세션 정보를 서버에 저장하고 관리하며, 보안 측면에서 더 안전하지만 확장성과 독립성 면에서는 제한적일 수 있다. 따라서 애플리케이션의 요구사항과 환경에 맞게 적절한 방식을 선택해야 한다.
리프래시 토큰
리프래시 토큰
리프래시 토큰은 서버에서 발급하며, 쿠키나 http 요청 헤더에 담아 클라이언트와 서버 간의 인증을 수행한다.
일정 시간마다 토큰을 갱신하거나 사용자의 요청에 따라 갱신한다.
JWT 액세스 토큰이 만료된 경우 ,클라이언트는 리프래시 토큰을 사용해 새로운 액세스 토큰을 발급받아야 한다.
따라서 우리 프로젝트에서 인증 서버는 소셜 로그인을 처리하기 위한 소셜 서비스의 OAuth 2.0 인증 서버를 의미한다.
스프링 부트 서버는 클라이언트로부터 받은 인증 정보를 이용해 소셜 서비스의 API를 호출하고, 그 결과를 클라이언트에게 반환하는 역할을 수행한다.
본 프로젝트에서는 OAuth 2.0 Authorization Code Grant Type을 사용한다.
이 방식은 일반적으로 클라이언트(리액트가 소셜 서비스(카카오, 구글 등)로부터 인증 코드를 받아, 이를 서버(스프링)로 보내 인증 코드와 함께 Access Token을 요청하고, Access Token을 받아 서버로부터 보호된 리소스(사용자 정보 등)에 접근할 수 있는 방식이다.
소셜 로그인
소셜 로그인?
소셜 로그인은 사용자가 다른 웹사이트나 앱에서 이미 사용하고 있는 소셜 미디어 서비스의 계정을 사용해 새로운 웹사이트나 앱에 로그인할 수 있는 기능을 말한다.
예를 들어 Facebook, Google, Kakao 드으이 소셜 미디어 계정을 사용해 다른 웹사이트나 앱에 로그인할 수 있다.
소셜 로그인은 사용자가 다른 웹사이트나 앱에 가입할 필요 없이 손쉽게 로그인할 수 있으므로 ,사용자 경험을 향상시키고 보안성을 높일 수 있다.
또한, 웹사이트나 앱에서 별도로 사용자 정보를 관리할 필요가 없으므로 개발자 입장에서 편리하다는 장점을 가진다.
소셜 로그인의 장단점
장점
사용자 친화적
소셜 로그인은 사용자가 웹사이트나 앱에 새로운 계정을 만들 필요가 없으므로 사용자에게 편의성을 제공한다.
로그인 정보 수집 용이
웹사이트나 앱에서 사용자 정보를 수집하는 데 도움이 된다.
사용자가 로그인하면 소셜 미디어 회사는웹사이트나 앱에서 사용자 정보를 수집하도록 허용하는 권한을 부여한다.
보안
사용자의 로그인 정보를 암호화하여 보호한다.
일부 소셜 미디어 회사는 사용자가 로그인할 때 두 단계 인증을 사용하도록 권장한다.
사용자 유지
소셜 로그인은 사용자의 계정을 유지하는 데 도움이 된다.
사용자가 웹사이트나 앱에서 로그인할 때마다 매번 새로운 계정을 만들지 않아도 된다.
단점
개인정보 보호
소셜 로그인을 사용하면 개인정보가 다른 회사에 공유될 가능성이 있다.
사용자가 로그인할 때 사용자 정보가 수집되어 다른 회사에서 사용될 수 있다.
종속성
소셜 로그인을 사용하면 해당 소셜 미디어 회사가 서비스를 중단하거나사용자 계정을 삭제하는 경우 웹사이트나 앱에 로그인할 수 없게 된다.
사용자 경험
일부 사용자는 소셜 로그인을 사용하지 않고 자체 계정을 만들기를 원할 수 있다.
또한, 일부 사용자는 다른 사람의 로그인 정보를 사용해 소셜 로그인을 사용하려 할 수 있다.
속도
소셜 로그인은 추가적인 인증 단계가 있기 때문에 로그인 프로세스가 더 느릴 수 있다.
결론적으로, 소셜 로그인은 사용자에게 많은 편의성을 제공하지만, 개인정보 보호와 종속성 등의 단점도 있따.
소셜 로그인 과정
소셜 로그인 과정에서 가장 중요한 것은 두가지이다.
인증처리 완료 - 인증 코드드
권한 부여 - 액세스 토큰
일반적으로 소셜 서버로부터 인증 토큰과 액세스 토큰을 발급받아 해당 소셜 서비스에 사용자 정보를 요청한다.
본 프로젝트에서 소셜 로그인은 다음과 같이 진행된다.
클라이언트(React)에서 소셜 로그인 버튼을 클릭하면, 해당 소셜 서비스의 로그인 페이지로 이동하게 된다.
사용자가 해당 소셜 서비스에 로그인하면, 해당 서비스는 사용자 정보를 포함한 인증 코드(authorization code)를 클라이언트에게 반환한다.
클라이언트(React)는 반환된 인증 코드를 가지고, 스프링 부트 서버에 인증 코드를 보내 인증 코드를 교환한다.
스프링부트 서버는 교환한 인증 코드를 사용해 해당 소셜 서비스에서 사용자 정보를 요청하고, 소셜 서비스로부터 받은 사용자 정보를 가지고 ㅡ프링 시큐리티에서 제공하는 Principal 객체를 생성한다.
그 후, 스프링 시큐리티는 Principal 객체를 이용해 로그인을 처리하고 ,클라이언트에게 access token을 반환한다.
클라이언트는 access token을 이용해 다른 API 요청을 할 수 있다.
따라서, 소셜 로그인 과정은 다음과 같다.
클라이언트(React)에서 소셜 로그인 버튼을 클릭한다.
해당소셜 서비스의 로그인 페이지로 이동 후 로그인한다.
인증 코드를 반환받는다.
클라이언트(React)가 스프링 부트 서버에 인증 코드를 보내 교환한다.
스프링 부트 서버가 해당 소셜 서비스에 사용자 정보를 요청하고, 소셜 서비스로부터 받은 사용자 정보를 가지고 Principal 객체를 생성한다.
스프링 시큐리티는 Principal 객체를 이용해 로그인 처리 후, 클라이언트에게 access token을 반환한다.
Spring Security에서 OAuth2를 구현할 대, 각 소셜 서비스마다 provider의 설정 정보가 달라 provider를 별도로 작성해줘야 한다.
예를 들어, Kakao와 Google은 OAuth2 프로토콜을 사용하지만, 각각의 소셜 서비스는 사용자 정보를 요청할 때 필요한 인증 정보 (ex. API Key, Secret Key 등)가 다르다.
또한, 각 소셜 서비스에서 사용자 정보를 반환하는 API의 URL이 다를 수 있다.
따라서, 각각의 소셜 서비스에 대한 provider를 작성하여 해당 서비스의 설정 정보를 입력해줘야 Spring Security에서 OAuth2를 구현할 수 있다.
이러한 설정을 통해 소셜 서비스의 API를 호출해 사용자 정보를 가져올 수 있다.
[참고] 스프링 시큐리티에서 'oauth2-client' 라이브러리를 사용할 대, 서비스 제공 업체 (구글, 카카오 등)에 대한 설정을 하기 위해서는 해당 업체의 'clientId', 'clientSecret', 'authorizationUri', 'tokenUri', 'userInfoUri' 등의 정보가 필요하다.
스프링 시큐리티에서는 이러한 정보를 각각의 provider에 대한 설정으로 관리한다. 예를 들어 google은 기본적으로 스프링 시큐리티에서 제공하는 'GoogleOAuth2ClientConfiguration' 클래스에서 미리 설정되어 있으므로, 따로 설정하지 않아도 된다.
그러나 kakao는 기본 제공되는 프로바이더가 아니기 때문에, 해당 정보를 별도로 설정해주어야 한다. 따라서 yml 파일에서 kakao에 대한 provider를 설정해주는 것이다.
SecurityConfig
@Slf4j
@Configuration
@RequiredArgsConstructor
public class SecurityConfig {
private final CustomOAuth2UserService oAuth2UserService;
private final OAuth2SuccessHandler oAuth2SuccessHandler;
private final OAuth2FailureHandler oAuth2FailureHandler;
private final JwtProcess jwtProcess;
private final RefreshTokenRedisRepository refreshTokenRedisRepository;
@Bean
public BCryptPasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
public class CustomSecurityFilterManager extends AbstractHttpConfigurer<CustomSecurityFilterManager, HttpSecurity> {
@Override
public void configure(HttpSecurity http) throws Exception {
AuthenticationManager authenticationManager = http.getSharedObject(AuthenticationManager.class);
http.addFilter(new JwtAuthenticationFilter(authenticationManager, jwtProcess, refreshTokenRedisRepository));
http.addFilter(new JwtAuthorizationFilter(authenticationManager, jwtProcess));
}
}
@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
http.headers().frameOptions().disable(); // iframe 허용안함
http.csrf().disable(); // csrf 허용안함
http.cors().configurationSource(configurationSource());
// 인증 실패 처리
http.exceptionHandling().authenticationEntryPoint((request, response, authException) -> {
CustomResponseUtil.fail(response, "로그인이 필요합니다", HttpStatus.UNAUTHORIZED);
});
// 권한 실패
http.exceptionHandling().accessDeniedHandler((request, response, e) -> {
CustomResponseUtil.fail(response, "권한이 없습니다", HttpStatus.FORBIDDEN);
});
http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS);
http.formLogin().disable();
http.httpBasic().disable();
// 필터 적용
http.apply(new CustomSecurityFilterManager());
http.authorizeHttpRequests()
.antMatchers("/api/auth/**").authenticated()
.antMatchers("/api/admin/**").hasRole("" + AccountEnum.ADMIN)
.anyRequest().permitAll();
http
.oauth2Login().loginPage("/token/expired")
.successHandler(oAuth2SuccessHandler)
.failureHandler(oAuth2FailureHandler)
.userInfoEndpoint().userService(oAuth2UserService);
return http.build();
}
public CorsConfigurationSource configurationSource() {
CorsConfiguration configuration = new CorsConfiguration();
configuration.addAllowedHeader("*");
configuration.addAllowedMethod("*"); // GET, POST, PUT, DELETE (Javascript 요청 허용)
configuration.addAllowedOriginPattern("*"); // 모든 IP 주소 허용 (프론트 엔드 ip만 허용하도록 할 수도 있다.)
configuration.setAllowCredentials(true); // 클라이언트에서 쿠키 요청 허용
configuration.addExposedHeader(JwtVO.ACCESS_TOKEN_HEADER);
configuration.addExposedHeader(JwtVO.REFRESH_TOKEN_HEADER);
UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
source.registerCorsConfiguration("/**", configuration); // 모든 주소요청에 위 설정을 적용
return source;
}
}
스프링 시큐리티 설정 파일이다.
OAuth2를 이용한 소셜 로그인 기능, JWT 토큰 인증 방식 등을 설정한다.
JWT 토큰으로 인증을 처리하고, OAuth2를 이용해 사용자 정보를 가져온다.
oauth2Login() 메서드를 사용해 OAuth2 로그인 설정을 수행한다.
successHandler(), failureHandler()는 로그인 성공, 실패 시 수행할 동작을 지정한다.
userInfoEndpoint().userService()는 OAuth2에서 사용자 정보를 가져오는 서비스를 지정한다.
PrincipalDetails
public class PrincipalDetails implements OAuth2User, UserDetails {
private Account account;
private Map<String, Object> attributes;
public PrincipalDetails(Account account) {
this.account = account;
}
public PrincipalDetails(Account account, Map<String, Object> attributes) {
this.account = account;
this.attributes = attributes;
}
public Account getAccount() {
return account;
}
@Override
public Map<String, Object> getAttributes() {
return attributes;
}
@Override
public Collection<? extends GrantedAuthority> getAuthorities() {
Collection<GrantedAuthority> authorities = new ArrayList<>();
authorities.add(() -> "ROLE_" + account.getRole());
return authorities;
}
@Override
public String getPassword() {
return account.getPassword();
}
@Override
public String getUsername() {
return account.getUsername();
}
@Override
public boolean isAccountNonExpired() {
return true;
}
@Override
public boolean isAccountNonLocked() {
return true;
}
@Override
public boolean isCredentialsNonExpired() {
return true;
}
@Override
public boolean isEnabled() {
return true;
}
@Override
public String getName() {
return account.getId() + "";
}
}
PrincipalDetails 클래스는 OAuth2User와 UserDetails 인터페이스를 구한다.
UserDetails 클래스의 경우 소셜 로그인이 아닌 UserDetailsService를 인터페이스를 구현할 때 필요한 것으로 이 글에서는 다루지 않는다.
OAuth2User는 Spring Security의 OAuth2 클라이언트 인증 과정을 통해 인증된 사용자 정보를 나타내는 인터페이스이다.
OAuth2 인증 서버로부터 전달받은 사용자 정보를 캡슐화하여 제공하며, 사용자 이름, 이메일, 프로필 사진 등의 정보를 제공한다.
OAuth2User 인터페이스를 사용하면, OAuth2 클라이언트를 통해 로그인한 사용자 정보를 손쉽게 가져올 수 있다.
예를 들어, 구글(Google) OAuth2 인증 서버로부터 인증된 사용자 정보를 다음과 같이 가져올 수 있다.
위 코드에서 @AuthenticationPrincipal 애노테이션은 현재 인증된 사용자 정보를 가져오는 데 사용된다.
OAuth2User 인터페이스를 구현하는 객체가 파라미터로 전달되면, 해당 객체를 사용해 사용자 정보를 가져올 수 있다.
OAuth2User 인터페이스를 사용해 소셜 로그인 기능을 구현할 경우, 각 OAuth2 인증 서버마다 제공하는 사용자 정보의 형식이 다를 수 있다.
이에 따라, OAuth2User 인터페이스를 구현한 구현체도 서로 다를 수 있다.
이를 고려해, 각 OAuth2 인증 서버별로 사용자 정보를 가져오는 구현체를 제공하는 OAuth2UserService 인터페이스가 제공된다.
이를 사용해, 각 OAuth2 인증 서버마다 사용자 정보를 가져오는 로직을 구현할 수 있다.
OAuth2User 인터페이스는 OAuth2 인증 프로토콜을 통해 인증된 사용자의 정보를 나타내며, 이 인터페이스는 다음과 같은 메서드를 제공한다.
getName() : 사용자 이름을 반환한다.
getAuthoriteis() : 사용자의 권환을 반환한다.
getAttributes() : 사용자 정보를 담은 Map 객체를 반환한다.
OAuth2UserService
@Slf4j
@Service
@RequiredArgsConstructor
public class CustomOAuth2UserService extends DefaultOAuth2UserService {
private final AccountRepository accountRepository;
@Override
public OAuth2User loadUser(OAuth2UserRequest userRequest) throws OAuth2AuthenticationException {
OAuth2User oAuth2User = super.loadUser(userRequest);
return processOAuth2User(userRequest, oAuth2User);
}
private OAuth2User processOAuth2User(OAuth2UserRequest userRequest, OAuth2User oAuth2User) {
Map<String, Object> attributes = oAuth2User.getAttributes();
// Attribute를 파싱해서 공통 객체로 묶는다. 관리가 편함.
OAuth2UserInfo oAuth2UserInfo = null;
String registrationId = userRequest.getClientRegistration().getRegistrationId();
String username = "";
if (registrationId.equals("google")) {
log.debug("구글 로그인 요청!");
String providerId = oAuth2User.getAttribute("sub");
username = registrationId + "_" + providerId;
oAuth2UserInfo = new GoogleUserInfo(attributes);
} else if (registrationId.equals("kakao")) {
log.debug("카카오 로그인 요청!");
long providerId = (long) attributes.get("id");
username = registrationId + "_" + providerId;
oAuth2UserInfo = new KakaoUserInfo(attributes);
} else {
log.error("지원하지 않는 소셜 로그인");
throw new OAuth2AuthenticationException("지원하지 않는 소셜 로그인입니다");
}
Optional<Account> accountOptional = accountRepository.findByUsername(username);
Account account;
String oauthEmail = oAuth2UserInfo.getEmail();
if (accountOptional.isEmpty()) {
account = Account.builder()
.username(username)
.email(oauthEmail)
.role(AccountEnum.CUSTOMER)
.build();
accountRepository.save(account);
} else {
account = accountOptional.get();
}
return new PrincipalDetails(account, attributes);
}
}
CustomOAuth2UserService 클스는 DefaultOAuth2UserService 클래스를 상속받아 OAuth2User 인터페이스를 구현한다.
DefaultOAuth2UserService는 Spring Security OAuth2 클라이언트에 의해 발행된 인증 코드(authentication code)를 교환하여 사용자의 OAuth2User 객체를 가져오는 기능을 제공하는 Spring Security의 구현체이다.
DefaultOAuth2UserService는 OAuth2UserService 인터페이스를 구현하고 있으며, loadUser() 메서드를 구현한다.
OAuth2User 인터페이스는 OAuth2 인증을 통해 인증된 사용자 정보를 제공한다.
loadUser 메서드는 OAuth2UserRequest 객체를 인자로 받아 OAuth2User 객체(PrincipalDetails)를 반환한다.
이 메서드는 OAuth2 인증 요청이 들어올 때 실행되며, OAuth2Provider의 인증 서버로부터 OAuth2 사용자 정보를 가져오기 위해 사용된다.
processOAuth2User 메서드는 OAuth2UserRequest와 OAuth2User객체를 인자로 받아, OAuth2UserInfo 인터페이스를 구현한 구현체인 GoogleUserInfo 또는 KakaoUserInfo 클래스 객체를 생성하고, 해당 클래스에서 제공하는 정보를 토대로 회원가입 또는 로그인을 수행한다.
회원가입이 수행되는 경우, 사용자 정보를 저장한 후, PrincipalDetails 객체를 생성해 반환한다.
위 코드는 OAuth2Provider로부터 받아온 사용자 정보를 파싱해 회원가입 또는 로그인 처리를 하고, 인증된 사용자 정보를 기반으로 PrincipalDetails 객체를 생성해 반환한다.
파라미터로 액세스 토큰과 리프래시 토큰이 노출된다. 이것은 다음과 같은 이유로 좋지 않다.
1. 보안 위협 - 파라미터로 토큰을 노출하면 다른 사람이 해당 토큰을 가로채 악용할 수 있다. - 이는 악성 공격자가 사용자 계정을 해킹하거나 데이터를 수정 또는 삭제할 수 잇는 문제를 발생시킬 수 있다.
2. 토큰 만료 - 보안상의 이유로 토큰은 일정 기감나다 갱신되어야 한다. - 파라미터로 토큰을 전송하면 해당 토큰이 노출될 가능성이 높기 때문에, 만료되기 전에 새로운 토큰으로 교체해야 할 수도 있다.
3. 로깅 - 파라미터에 포함된 토큰은 서버 로그에 기록될 간으성이 높다. - 이는 민감한 정보를 저장하는 데 사용되는 경우, 중요한 정보가 노출될 수 있기 때문에 보안 문제를 야기할 수 있다.
4. 보안 강화 요구 사항 - 일부 규제 기관에서는 보안을 강화하기 위해 파라미터에 토큰을 포함시키는 것을 금지하고 있다.
문제점 해결!! Redirection 시에는 헤더에 토큰을 넘겨줄 수 없어 쿠키에 토큰값을 담아 문제를 해결한다. 로그인을 수행하면 다음과 같이 쿠키에 토큰값이 담기는 것을 확인할 수 있다. 클라이언트에서는 해당 쿠키값을 조회해 사용하면 된다.
JwtProcess
@Component
public class JwtProcess {
@Value("${jwt.subject}")
private String jwtSubject;
@Value("${jwt.secret}")
private String secret;
public String createAccessToken(PrincipalDetails principalDetails) {
Account account = principalDetails.getAccount();
return createNewAccessToken(account.getId(), account.getRole().toString());
}
public String createNewAccessToken(Long accountId, String role) {
String jwtToken = JWT.create()
.withSubject(jwtSubject)
.withExpiresAt(new Date(System.currentTimeMillis() + JwtVO.ACCESS_TOKEN_EXPIRATION_TIME))
.withClaim("id", accountId)
.withClaim("role", role)
.sign(Algorithm.HMAC512(secret));
return JwtVO.TOKEN_PREFIX + jwtToken;
}
public String createRefreshToken(String accountId, String role) {
String refreshToken = JWT.create()
.withSubject(jwtSubject)
.withExpiresAt(new Date(System.currentTimeMillis() + JwtVO.REFRESH_TOKEN_EXPIRATION_TIME))
.withClaim("id", accountId)
.withClaim("role", role)
.sign(Algorithm.HMAC512(secret));
return JwtVO.TOKEN_PREFIX + refreshToken;
}
// 토큰 검증 (return 되는 LoginUser 객체를 강제로 시큐리티 세션에 직접 주입할 예정) - 강제 로그인
public PrincipalDetails verify(String token) {
DecodedJWT decodedJWT = isSatisfiedToken(token);
Long id = decodedJWT.getClaim("id").asLong();
String role = decodedJWT.getClaim("role").asString();
Account account = Account.builder().id(id).role(AccountEnum.valueOf(role)).build();
return new PrincipalDetails(account);
}
public DecodedJWT isSatisfiedToken(String token) {
return JWT.require(Algorithm.HMAC512(secret)).build().verify(token);
}
}
JwtVO
public interface JwtVO {
public static final int ACCESS_TOKEN_EXPIRATION_TIME = 1000 * 60 * 30; // 30분
public static final int REFRESH_TOKEN_EXPIRATION_TIME = 1000 * 60 * 60 * 24 * 14; // 2주
public static final String TOKEN_PREFIX = "Bearer ";
public static final String ACCESS_TOKEN_HEADER = "Authorization";
public static final String REFRESH_TOKEN_HEADER = "Refresh-Token";
}
