Spring Security) REST API 인증 기법

1. Basic 인증

• 모든 HTTP 요청에 아이디와 비밀번호를 같이 보내는 것
• 가장 간단한 방식

Basic 인증 방식

1. 최초 로그인한 후 HTTP 요청 헤더의 Authorization 부분에 Basic: <ID>:<Password>처럼 아이디와 비밀번호를 콜론으로 이어 붙인 후 Base64로 인코딩한 문자열을 함께 보낸다.
2. 서버에서 요청을 수신 후 문자열을 디코딩 해 아이디와 비밀번호를 찾아낸 후 데이터베이스와 비교한다.

Authorization: Basic <Base64로 인코딩한 문자열>

Basic 단점

1. 아이디와 비밀번호를 노출한다
   • 인코딩을 하더라도 보안 목적으로 한 것이 아니기 때문에 디코더만 있다면 누구나 원래의 아이디와 비밀번호를 확인할 수 있다. 중간에 가로채는(MITM)것에 취약하기 때문에 반드시 HTTPS와 사용해야한다.
2. 사용자를 로그아웃 시킬 수 없다.
   • 모든 요청이 일종의 로그인 요청이기 때문이다.
3. 사용자의 계정 정보가 있는 저장 장소(인증DB와 인증서버)에 과부하가 걸릴 확률이 높다.
   • 매 요청마다 인증을 처리해야하니 많은 요청이 들어온다면 과부하가 걸리기 쉽다.
   • 이러한 과부하로 서버가 오류나면 전체시스템이 멈추는, 즉 인증 서버가 단일 장애점이 되는 경우가 생긴다.

2. 토큰 기반 인증

• 토큰을 이용하는 방식
• 토큰은 사용자를 구별할 수 있는 문자열

Token 인증 방식

• 최초 로그인 시 서버가 자기만의 방식들로 토큰을 만들고 저장 후 사용자에게 반환
• 최초 로그인 이후 부터는 요청에 아이디와 비밀번호 대신 토큰을 넘기고 서버는 이를 검색 및 검증한다.

Authorization: Bearer <TOKEN>

Token 장점

1. 아이디와 비밀번호를 매번 전송할 필요가 없어 Basic 방식보다 안전하다.
2. 서버가 토큰을 마음대로 생성할 수 있으므로 사용자의 인가 정보나 유효시간을 관리할 수 있다.

Token 단점

1. Basic에서도 존재한 스케일 문제를 해결할 수 없다.

3. JSON 웹 토큰 (JWT) 인증

• 전자 서명된 토큰을 이용하는 방식으로 그 중 하나가 JWT (JSON Web Token)
• JWT는 JSON 형태로 된 토큰
• 스케일 문제를 해결할 수 있음

구성

• header
  • typ : 토큰의 타입
  • alg : 토큰의 서명을 발행하는 데 사용된 해시 알고리즘의 종류
• payload
  • sub : 토큰의 주인을 판별하는 식별자, ID처럼 유일한 식별자여야 한다.
  • iss : 토큰을 발행한 주체
  • iat : 토큰의 발행 날짜와 시간
  • exp : 토큰이 만료되는 시간
• signature : 토큰을 발행한 주체가 발행한 서명으로 토큰의 유효성 검사에 사용

JWT 방식

• JWT에서 전자 서명이란 헤더,페이로드와 secret키를 이용해 해시 함수에 돌린 암호화한 결과 값이다.
• 토큰을 훔쳐갈 수 있으므로 반드시 HTTPS로 통신해야 한다.

1. 최초 로그인 시 서버는 사용자의 아이디와 비밀번호를 서버에 저장된 정보와 비교해 인증하고 인증된 사용자인 경우 사용자의 정보를 이용해 헤더와 페이로드를 작성하고 시크릿키로 헤더,페이로드 부분을 전자 서명한다.

2. 전자 서명의 결과 값을 헤더,페이로드,서명으로 이어붙이고 base64로 인코딩 한 후 반환한다.

3. 누군가 이 토큰으로 리소스 접근을 요청하면 서버는 토큰을 디코딩하고 헤더,페이로드 와 서명 부분으로 나눈다.

4. 서버는 헤더,페이로드와 시크릿 키로 전자 서명을 만들고 이를 HTTP 요청이 갖고온 서명 부분과 비교해 토큰의 유효성 검사를 한다.

5. 서명이 일치하지 않을 경우 인증 서버에 토큰의 유효성에 대해 물어볼 필요가 없으므로 서버에 부하를 일으키지 않는다.