spring security 인증(Authentication)

• 1.http요청이 오면 authenticationFilter가 요청을 토대로 usernamePasswordAuthenticationTocken을 생성

• 2.authenticationmanager의 구현체(ProviderManager)가 이 usernamePasswordAuthenticationTocken을 Filter로부터 받아
  authenticationProvider에게 전달.

• 3.authenticationProvider는 이 Tocken을 통해 UserDetailService에서 그에 맞는 사용자 정보가 담긴 Authentication객체를 넘겨받음.

• 4.최초의 Filter에까지 Authentication객체가 넘어가면 이것이 SecurityContext에 저장됨.

-하지만 위의 흐름외에도 다양한 방식으로 필터체인을 커스터마이징 할 수 있음.

쿠키,session와 jwt

로그인을 한 후 사용자 정보를 유지하는 전통적인 방법은 세션이었다.
http는 stateless하기 때문에 사용자의 정보가 유지되기 위해서는 별도의 방법이 필요하다. 이때, 우선은 브라우저에서 쿠키를 만들어 여기에 정보를 담을 수 있다.
하지만 이 쿠키는 보안상 취약,용량의 제한, 네트워크에 대한 부하등의 단점이 있어 보완이 필요하다.

이 보완법이 세션을 이용하는 것이다. 세션은 클라이언트의 인증정보를 쿠키가 아닌 서버에 저장하고 관리하는 방법이다. 클라이언트의 식별자인JSESSIONID(세션ID)를 쿠키에 저장하고 클라이언트가 요청과 JSESSIONID를 함께 보내면 서버가 이 식별자의 유효성을 판단해 세션으로부터 사용자정보를 전달한다.
하지만 이 방법은 세션이 서버에 쌓이며 부하를 일으킬 수 있다.

때문에 세션방식과 다른 방법인 jwt가 사용된다.
jwt는 클라이언트 정보를 암호화,압축 시켜 tocken으로 만든 뒤 클라이언트와 서버가 주고받는 방법이다.

클라이언트의 로그인 요청이 들어오면 서버는 검증 후 클라이언트의 정보를 payload에 담아 암호화해 JWT를 발급한다. 클라이언트는 이 jwt를 저장해두고 서버에 요청시마다 함께보내며 서버는 이 JWT를 복호화해 변조여부, 클라이어트의 정보 확인을 해 응답한다.
이 방식은 세션방식과 다르게 정보를 별도의 공간에 저장하지 않아 서버과부하가 적고, 확장성이 좋다. 하지만 JWT의 길이가 길어 네트워크에 부하가 상대적으로 크고 토큰 탈취의 위험 떄문에 refresh tocken등의 보안전략이 필요하다.

spring jwt방식

jwt는
header: 어떤 알고리즘으로 암호화 했나
payload: 정보들 저장
signatur: 서명, 위의 정보들을 암호화한 결과
로 이뤄져 있다.

1. 클라이언트가 로그인 시도.
2. 서버가 jwt를 만듦.(서버가 가진 secret key이용해 암호환된 결과)
3. 서버가 jwt를 클라이언트에 보내줌.
4. 클라이언트가 jwt와 함꼐 요청을 보냄.
5. 서버가 jwt를 복호화하여 자신이 인정한 합당한 token인지 확인.(인증)
   -> 복호화한 데이터의 header와 payload를 자신의 키로 암호화한 결과==클라이언트가 보낸 jwt의 signature부분 // 비교

reference

http://yoonbumtae.com/?p=3000
https://brunch.co.kr/@springboot/491
https://tecoble.techcourse.co.kr/post/2021-07-10-understanding-oauth/
https://imbf.github.io/spring/2020/06/29/Spring-Security-with-JWT.html
https://webfirewood.tistory.com/115

https://www.callicoder.com/spring-boot-security-oauth2-social-login-part-3/