내일배움캠프 Spring 23일차 TIL

스프링 숙련

1. Bean을 수동으로 등록하는 방법

• @Component를 사용하면 @ComponentScan에 의해 자동으로 스캔되어 해당 클래스를 Bean으로 등록 해주며 해당 방법으로 Bean을 등록시키는게 좋다.
• 그렇다면 Bean 수동 등록은 언제 하면 좋은가?
  - 기술적인 문제나 공통적인 관심사를 처리할 때 사용하는 객체들을 수동으로 등록하는 것이 좋습니다.

• @Configuration
  public class PasswordConfig {
    @Bean
    public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
    }
  }

  • Bean으로 등록하고자하는 객체를 반환하는 메서드를 선언하고 @Bean을 설정합니다.
  • Spring 서버가 뜰 때 Spring IoC 컨테이너에 'Bean'으로 저장됩니다.

2. 같은 타입의 Bean이 2개라면?

• 같은 타입의 Bean이 2개 이상이면 @Autowired를 사용 시 오류가 발생한다.
  - 이럴 경우 해당 Bean의 이름을 정확히 명시해 주면 사용할 수 있다.
  • @Primary를 사용하면 같은 타입의 Bean이 여러 개 있더라도 우선 @Primary가 설정된 Bean 객체를 주입 해줍니다.
  • @Qualifier를 사용해도 @Primary와 같은 효과를 낸다. 하지만 같은 타입의 Bean들에 Qualifier와 Primary가 동시에 적용되어있다면 Qualifier의 우선순위가 더 높습니다.

3. 인증과 인가

• 인증 : 인증은 해당 유저가 실제 유저인지 인증하는 개념입니다.
• 인가 : 인가는 해당 유저가 특정 리소스에 접근이 가능한지 허가를 확인하는 개념입니다.
  예를들어 관리자 페이지-관리자 권한 같은것들을 들 수 있습니다.

3.1 웹 어플리케이션 인증

• 구조 : 보통 서버-클라이언트(두 요소는 멀리 떨어져 있음)
• 특성 : Http 라는 프로토콜을 이용하여 통신하는데, 그 통신은 비연결성(Connectionless) 무상태(Stateless)로 이루어짐
  - 비연결성 : 서버와 클라이언트가 연결되어 있지 않다는 것
  • 무상태 : 서버가 클라이언트의 상태를 저장하지 않는다는 것
• 인증 방식
  • (쿠키-세션) 방식 인증
    1. 사용자의 로그인 요청
    2. 서버의 아이디 비밀번호 대조
    3. 정보 일치시 인증 통과 -> 세션 저장소에 로그인 정보 입력
    4. 세션 저장소에서 유저와 관련 없는 난수 session-id 발급
    5. 서버는 로그인 요청 응답으로 session-id 발급
    6. 클라이언트는 session-id를 쿠키 저장소에 보관, 이후 요청에 session-id를 같이 보냄
    7. 클라이언트 요청에 session-id가 포함되어있으면 서버는 세션 저장소에서 쿠키를 검증
    8. 유저정보가 있다면 로그인 되어있는 사용자
    9. 로그인 된 유저에 대한 응답을 전달
  • (JWT 기반 인증)
    1. 사용자의 로그인 요청
    2. 서버의 아이디 비밀번호 대조
    3. 정보 일치시 인증 통과 -> 유저의 정보 JWT 암호화
    4. 서버는 로그인 요청의 응답으로 JWT 토큰 제공
    5. 클라이언트는 토큰을 보관하고 요청때 같이 토큰을 보냄
    6. 클라이언트의 요청에서 토큰을 발견 시 서버는 토큰 검증
    7. 로그인 된 유저에게 응답 제공

• 쿠키 vs 세션
  • 쿠키 : 클라이언트에 저장될 목적으로 생성한 작은 정보를 담은 파일 입니다.
  • 세션 : 서버에서 일정시간 동안 클라이언트 상태를 유지하기 위해 사용됩니다.
• JWT(Json Web Token)
  • 내용 : JSON 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token 입니다.
  • 사용목적 : 세션 사용 시 서버가 2대 이상일 경우 클라이언트 정보가 어느 서버에 있는지 알 수 없음 그렇게 되면 모든 서버가 공유하는 세션 저장소를 생성해야 함 하지만 JWT를 사용하면 같은 Secret Key 값을 가지고 있는 것 만으로도 해결 가능
  • 장/단점
    - 장점 : 동시 접속자가 많을 때 서버 측 부하 낮춤
    - 단점 : 구현의 복잡도 증가, JWT에 담는 내용이 커질 수록 네트워크 비용 증가
  • 사용흐름
    1. Client 가 username, password 로 로그인 성공 시 서버에서 "로그인 정보" → JWT 로 암호화
    2. 서버에서 직접 쿠키를 생성해 JWT를 담아 Client 응답에 전달
       (JWT 전달방법은 개발자가 정함)
    3. 브라우저 쿠키 저장소에 자동으로 JWT 저장됨
    4. 클라이언트에서 JWT를 통해 인증 - 서버에 API 요청 시 쿠키에 포함된 JWT를 찾아서 사용
    5. Client 가 전달한 JWT 위조 여부 검증 + JWT 유효기간이 지나지 않았는지 검증
    6. JWT → 에서 사용자 정보를 가져와 확인
  • 구조
    - JWT 는 누구나 평문으로 복호화 가능하다 + Secret Key가 없으면 수정 불가
  • 스프링부트에서의 사용 흐름
    1. JWT 생성
    2. JWT Cookie에 저장
    3. 받아온 Cookie의 Value인 JWT 토큰 substring
    4. JWT 검증
    5. JWT에서 사용자 정보 가져오기