ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • (2023-11-10 TIL) Bean 수동등록, 인증과 인가, 쿠키세션인증방식, 그리고 JWT
    TIL 2023. 11. 10. 17:45

    Bean 수동등록에 들어가기 앞서서

    평소라면 @Component를 사용하면 @CommponentScan에 의해 자동으로 스캔되어 해당 클래스를 Bean으로 등록해준다. 그리고 일반적으로, @Component를 사용한 자동등록이 많이 사용되고 훨씬 효율적이다.

     

    왜 Bean 자동등록이 효율적일까?

      1. 프로젝트 규모가 커질 경우 Bean을 자동으로 등록하는 것이 훨씬 편하다.

      2. 비지니스 로직 관련 클래스들은 그 수가 많아 @Controller, @Service, @Repository annotation을 사용해 Bean으로 등록하고 관리하는것이 개발생산성에 유리하기 때문이다.

     

    그렇다면, Bean을 굳이 수동등록해야할 때와 이유에 대해 알아보자.

    Bean을 수동등록할 때는, 공통 로그 처리 등등 부가적이고 공통적인 기능을 처리할 때 사용하는 객체들을 다룰때이다.

     

    왜 기술적인 문제나 공통적인 관심사를 처리하는 객체를 수동등록할까?

      1. 비지니스로직 Bean보다 수가 적어 수동등록하기 부담스럽지 않다.

      2. Bean에서 문제가 발생했을때 해당 에러 위치 파악이 쉽다.

     

    Bean 수동등록 방법에 대해 알아보자.

      1. 메서드 위에 @Bean annotation을 설정한다.

      2. 메서드가 속해있는 클래스 위에 @Configuration 설정한다.

     

    Bean이 같은 타입으로 2개 등록하면 어떤일이 벌어지고 그 해결 방법은 무엇일까?

      하나의 인터페이스로 2개의 구현체를 만들고 Bean에 등록하는 것까지는 문제가 발생하지 않는다.

    문제는 @Autowired를 사용할때 발생한다.

     

    어떤 에러가 발생할까?

    Bean이 같은 타입으로 2개가 등록되어 생기는 문제로, 우리는 이를 명시해줘야한다.

     

    Bean을 명시하는 방법은 3가지가 있다.

      1. 등록된 같은 타입 2개중 Bean 하나의 이름을 명시한다.

           - 어떻게 이게 가능할까? @Autowired가 기본적으롤 Bean의 타입을 기준으로 DI를 지원하기 때문.

     

      2. @Primary 사용

          같은 타입의 Bean이 여러개 있더라도 @Primary가 붙은 Bean을 우선적으로 사용한다.

     

    3. @Qualifier("Bean타입 이름") 사용

          @Primary보다 우선순위가 높다. 그러므로, 주로 사용하는 Bean의 타입에 @Primary 사용, 지엽적으로 사용할때는            @Qualifier를 사용한다.

     

    인증과 인가

     

    인증(Authentification)이란?

      해당 유저가 실제 유저인지 인증하는 개념

     

    인가(Authorization)이란?

      해당 유저가 특정 리소스에 접근 가능한지 확인하는 개념

     

    HTTP 클라이언트와 HTTP 서버의 관계성

      1. 비연결성(Connectionless)

      2. 무상태성(Stateless)

     

    비연결성: 서버와 클라이언트가 계속 연결되지 않다.

    무상태성: 서버가 클라이언트의 상태를 저장하고 있지 않다.

     

    그렇다면 우리는 어떻게 인터넷을 연속성있게 사용할 수 있었을까?

    -> 이는 개발자들이 URL을 통해 연속적인 상황을 연출했다고 볼 수 있다.

     

    클라이언트와 서버가 계속 연결되지 않고 상태를 저장하지 않는다면, 우리가 어떤 사이트에 로그인한 정보가 남아있을 수 없다.

    그렇다면, 로그인(인증)의 경우는 어떻게 구현한걸까?

      1. 쿠키 세션 인증 방식

      2. JWT 기반 인증 방식

     

    쿠키 세션 인증 방식부터 알아보자.

      쿠키란?

        클라이언트에 저장될 목적으로 생성한 작은 정보를 담은 파일

        저장위치: 클라이언트(웹 브라우저)

        만료시점: 쿠키 저장시 설정된 만료일까지(브라우저 종료시도 유지 가능)

        보안: 취약(클라이언트에서 쿠키 정보를 쉽게 변형할 수 있음)

        구성요소: name, value, domain, path, expires

     

      

      세션이란?

        웹 사이트의 여러페이지에 걸쳐 사용되는 사용자 정보를 저장하는 방법을 의미한다.

        사용자가 브라우저를 닫아 서버와의 연결을 끝내는 시점까지 세션이라고 한다.

        저장위치: 웹 서버

        만료시점: 다음 조건 중 하나가 만족될 경우 만료된다.

                         1. 브라우저 종료시까지

                         2. 클라이언트 로그아웃 시까지

                         3. 서버에 설정한 유지기간까지 해당 클라이언트의 재요청이 없을 경우

      보안: 비교적 안전(서버에 저장되기때문)

    세션의 동작 방식

    아래는 위 동작 방식에 대한 설명이다.

      1. 클라이언트가 '1번 요청'을 한다.

      2. 서버가 세션ID를 생성하고 쿠키(Set-Cookie: ID=12A345)에 담아 응답헤더에 전달한다.

      3. 클라이언트가 쿠키에 세션ID를 저장한다.

      4. 클라이언트가 세션ID(Cookie: ID=12A345)를 포함하여 '2번 요청'을 한다.

      5. 서버가 세션ID를 확인하고, '1번 요청'과 같은 클라이언트임을 인지

     

    JWT 기반 인증 방식에 대해 알아보자.

    JWT란?

      JSON Web Toekn의 준말로, 웹에서 사용하는 JSON 형식의 토큰.

     

    JWT의 특징

      1. 인증에 필요한 정보를 암호화 시켜놓음

      2. 암호화된 JWT를 HTTP 헤더에 실어서 서버가 클라이언트를 식별할 수 있도록 하고 있다.

     

    쿠키 세션 방식과 JWT 기반 방식의 가장 큰 차이점.

    서버가 저장소를 가지냐 안 가지냐의 차이.

    쿠키 세션 방식은 서버가 저장소를 가져야하므로 비용이 발생

    JWT 기반 방식은 서버가 JWT토큰을 검증하기만 하면됨.

     

    JWT의 장점

      1. 동시접속자가 많을 때 서버 부하가 적음

      2. Client, Server가 다른 도메인을 사용할때

     

    JWT의 단점

      1. 구현 복잡도 증가

      2. JWT에 담은 내용이 클만큼 네트워크 비용 증가

      3. 기생성된 토큰 일부만 만료 불가 -> 만료기한을 줘서 해결가능

      4. Secret Key 유출 가능 -> 서버 조작이 가능하기 때문에, 비밀번호 같은 정보는 넣으면 안됨

     

    결론

    서버의 입장에서,

    JWT > 쿠키세션

     

     

     

     

Designed by Tistory.