[TIL] JWT

👋🏻 JWT : JSON Web Token

  - 데이터를 안전하고 간결하게 전송하기 위해 고안된 인터넷 표준 인증 방식

  - Json 포맷으로 사용자에 대한 속성을 저장하는 웹 토큰

  - 클라이언트에서 인증 정보를 토큰으로 보관하는 방법

  - 점(.)으로 나누어지는 세부문 존재

---

📍JWT의 구조

aaaaaaa . bbbbbb . ccccccc
-------   -------  --------
 Header   Payload  Signature

 (1) Header

{ 
    "alg" : "HS256",
    "typ" : "JWT"
}

  - 이것이 어떤 종류의 토큰인지, 어떤 알고리즘으로 sign 할지가 적혀있음

  - JSON 형태로 나타남

---

 (2) Payload

{
    "sub" : "someInformation",
    "name" : "philip",
    "iat" : 12312345
}

  - 서버에서 활용할 수 있는 유저의 정보가 담겨있음

  - 어떤 정보에 접근 가능한지에 대한 권한을 담을 수 있고 사용자의 유저 이름 등 필요한 데이터를 담을 수 있음

---

 (3) Signature

HMACSHA256(
     base64UrlEncode(header) + "." +
     base64UrlEncode(payload), secret)

  - Header, Payload를 base64 인코딩한 값과 salt 값의 조합으로 암호화된 값

  - 원하는 비밀키와 Header에서 지정한 알고리즘을 사용하여 암호화

  - base64 인코딩을 한 값은 누구나 쉽게 디코딩 가능 

     → 비밀키가 없다면 해독에 오랜 시간과 노력이 필요

---

💡 세션 기반 인증 

  - 서버 혹은 DB에 유저 정보를 담는 방식

  - 매번 인증이 필요하거나 권한 확인이 필요한 순간이 올 때마다 가지고 있는 세션 값과 일치하는지 확인

    + 매 요청마다 데이터베이스를 살펴보아야 함

      → 이 부담은 클라이언트에게 넘겨주기 위해 고안된 것이 토큰 기반 인증

💡 토큰 기반 인증

  - 클라이언트에서 인증 정보를 보관하기 위한 방법으로 고안됨

  - 클라이언트가 토큰을 가지고 서버에게 이를 보여주면 다양한 기능을 이용할 수 있는 방식

  - 여기서 토큰은 유저 정보를 암호화한 상태로 담을 수 있고 암호화 했기 때문에 클라이언트에 담을 수 있음 

    → 즉, 위험 ↓

---

📍JWT의 종류

 ▪️ 엑세스 토큰 : Access Token

 - 보호된 정보들(유저의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한 부여에 사용

 - 클라이언트가 처음 인증을 받게 될 때 엑세스 토큰과 리프레시 토큰을 모두 받음

    → But, 실제로 권한을 얻는 데 사용하는 토큰은 엑세스 토큰

 ▪️ 리프레시 토큰 : Refresh Token

 - 액세스 토큰의 유효기간이 만료된다면 리프레시 토큰을 사용하여 새로운 액세스 토큰 발급

 - 유저는 다시 로그인할 필요 없음

 - 탈취 등 위험으로 편의 보다 정보를 지키는 것이 중요하면 사용 X

---

📍 토큰 기반 인증 방식 : JWT의 장점

 ① 무상태성 및 확장성 : Statelessness & Scalability

  - 서버는 클라이언트에 대한 정보를 저장할 필요가 없음

    → 토큰 해독이 되는지만 판단

  - 클라이언트는 새로운 요청을 보낼 때 마다 ㄴ토큰을 헤더에 추가함으로 인증절차 완료

 ② 안정성

  - 암호화한 토큰을 사용

  - 암호화 키를 노출할 필요가 없음

 ③ 어디서나 생성 가능

  - 토큰을 생성하는 서버가 꼭 토큰을 만들지 않아도 됨

  - 토큰 생성용 서버를 만들거나 다른 회사에서 토큰 관련 작업을 맡기는 것 등 다양한 활용이 가능함

 ④ 권한 부여에 용이

  - 토큰의 payload(내용물) 안에 어떤 정보에 접근 가능한지 정의

  - ex) 사진과 연락처 사용 권한 부여 or 사진 사용 권한 부여 or 연락처 사용 권한 부여

---

📍 토큰 기반 인증 방식 : JWT의 단점

 ①  Payload 해독

  - Palyload는 base64로 인코딩 되어 있음

  - 토큰을 탈취하여 Payload를 해독하면 토큰 생성시 저장한 데이터 확인 가능

  - Payload에는 중요한 정보를 넣지 않아야 함

 ②  네트워크 부하

  - 토큰이 길어지면 네트워크에 부하를 줄 수 있음

  - 토큰에 저장하는 정보의 양이 많아질 수록 토큰의 길이는 길어짐

  - 요청마다 길이가 긴 토큰을 함께 전송하면 네트워크에 부하를 줄 수 있음

 ③  자동 삭제 불가

  - JWT의 장점 중 하나는 무상태성 → 상태를 저장하지 않음

  - 때문에 한 번 생성된 토큰은 자동으로 삭제되지 않으며 토큰 만료 시간을 추가해야 함

  - 토큰이 탈취된 경우 토큰의 기한이 만료될 때 까지 대처 불가능

 ④ 토큰의 저장

  - 토큰은 어딘가에 저장이 되어야 함

  - 클라이언트가 가지고 있다가 인증이 필요한 요청을 보낼 때 마다 함께 전송해야 함

---

💡스프링 시큐리티 세션 정책

http
   .sessionManagement()
   .sessionCreationPolicy(SessionCreationPolicy.정책상수)

①  SessionCreationPolicy.ALWAYS

  - 스프링 시큐리티가 항상 세션을 생성

②  SessionCreationPolicy.IF_REQUIRED

  - 스프링 시큐리티가 필요시 생성

③  SessionCreationPolicy.NEVER

  - 스프링 시큐리티가 생성하지 않지만 기존에 존재하면 사용

④  SessionCreationPolicy.STATELESS

  - 스프링 시큐리티가 생성하지도 않고 기존 것을 사용하지도 않음 (JWT 시 많이 사용하는 설정)

---

💡Spring CORS 설정하기

 ▪️ CORS (Cross-Origin Resource Sharing) 란 ?

  - 교차 출처 리소스 공유

  - 웹 브라우저에서 다른 출처의 자원을 공유하는 방법

  - 브라우저와 서버 간 외부 도메인 서버에 접근하기 위한 권한을 알려주는 메커니즘

  - 동일 출처(SOP)의 경우 웹 브라우저 상 보안상 이슈가 없지만 교차출어의 경우 보안상 이슈로 웹브라우저 상 에러메시지 발생

    → 이러한 문제를 해결하기 위해 CORS 처리를 해주어야 함

  ▸ Origin : 출처

  - https://test.com/443 

    ① 프로토콜 : https

    ② 호스트 : test.com

    ③ 포트번호 : 443

  - 즉, Origin은 프로토콜 + 호스트 + 포트번호를 합친 것과 같음

---

 ▪️ CorsConfiguration과 UrlBasedCorsConfiguratonSource를 이용하여 구현

  - CorsConfiguration : CORS 요청이 어떻게 허용 되고 origin, 헤더, 메소드 등이 처리되어야 하는지 방법 지정

---

📍 JWT Bearer 인증

 🔸 Session & Cookie 인증 방식

  - 사용자가 로그인 요청을 보내면 사용자를 확인하고 Session ID를 발급함

  - 발급한 ID를 통해 다른 요청과 응답을 처리하는 방식

---

 🔸 Token 인증 방식

  - 저장소 필요 없이 로그인 시 토큰을 발급하고 데이터 요청 시에 발급받은 토큰을 헤더를 통해 전달하여 응답을 받는 방식

   * 장점 *

   - 쿠키나 세션을 통한 인증보다 보안성이 강하고 효율적

     → 쿠키 인증은 쿠키에 사용자 정보를 담아 서버로 보내게 되는데 HTTP 통신을 사용하는 경우 정보가 유출되기 쉬움

     → 세션 인증은 세션 ID를 보내므로 쿠키에 비해 보안성이 높으나 서버에서 처리해야 하기 때문에 추가적인 DB 공간 필요

   - 토큰은 데이터가 인코딩 되어있지만 누구나 디코딩하여 데이터가 유출될 수 있지만 서명 필드가 헤더와 페이로드를 통해 만들어져

      데이터 변조 후 재전송을 막을 수 있음

   - Stateless 서버를 만들 수 있음

   - 인증정보를 OAuth로 이용할 수 있음

   * 요청 헤더 Authorization 필드의 구조 *

Authorization: <type> <credentials>

    - 일반적으로 토큰은 요청 헤더의 Authorization 필드에 담겨져 보내짐

---

  ▪️ Bearer 인증 타입

  - JWT or OAuth 에 대한 토큰 사용

---

 🔸 필터 생성

  ▪️ addFIlterBefore( 필터, 특정 필터 이름 ) / addFIlterAfter( )

  - SecurityFilterChain에 있는 필터 중 전/후로 필터를 적용해주는 메서드

  - 특정 필터 이름이 실행되기 전에 내가 만든 필터를 먼저 적용하게 됨

---

 🔸 토큰 적용

  ▪️ response.setCharacterEncoding("UTF-8")

  - 서블릿에서 화면에 데이터를 출력하기 위해서는 out.println을 사용하는데 UTF-8 지정하지 않으면

      물음표가 출력됨 → 이를 해결하기 위해 UTF-8 설정

  ▪️ request.setCharacterEncoding("UTF-8")

  - 입력한 값을 전송할 때 POST 방식으로 보내는 값이 한글일 경우, 깨지지 않게 전달하기 위해 사용

  ▪️ HttpServletRequest

  - ServletRequest를 상속

  - Http 프로토콜의 Request 정보를 서블릿에 전달하기 위한 목적으로 사용

  - 헤더 정보, 파라미터, 쿠키, URI, URL 등의 정보를 읽어들이는 메서드 가진 클래스

  - Body의 Stream을 읽어들이는 메서드를 가지고 있음

  ▪️ HttpServletResponse

  - ServletResponse를 상속

  - Servlet이 HttpServletResponse 객체에 Content Type, 응답코드, 응답 메시지를 담아 전송

---

  ▪️ Object Mapper

 - JSON 형태의 문자열을 JAVA 객체로 (readValue(json객체, 역직렬화를 시킬 클래스-파싱결과전달)

---

  ▪️ AuthenticationManager

  - anthenticate의 메서드를 가짐

---

📍 JWT Token

  🔹 JWT Token : 로그인

  

  ▪️ 인증 권한 테스트