99클럽 30일차 TIL: Basic 인증

#1. 오늘의 학습 키워드

Basic 인증에 대해

• JWT 와 OAuth 에 대해 알아보았다.
  • JWT
    • https://second-brain.tistory.com/46
    • 처음 로그인 성공 후 인증 정보가 담긴 Json 객체를 암호화한 JWT로 클라이언트가 서버에 인가된 요청을 보내는 방식
  • OAuth
    • https://second-brain.tistory.com/47
    • 사용하고자하는 서버로부터 직접 접근 권한을 받는 것이 아닌 서드파티 어플리케이션으로부터 권한을 부여받아서 서비스를 이용하는 방식
  • 이번엔 기본적인 인증 방식인 Basic 인증 에 대해 알아보자.

---

#2. 공부한 내용

1. Basic 인증

- ID, PW 자체로 인증 정보로 사용하는, 말그대로 가장 기본적인 인증 방식

• JWT 방식에서는 ID, PW를 client 에서 server 로 보내면, 직후 Http header 에는 id, pw 가 아닌 토큰을 통해 인증을 요청 때마다 수행한다.
  • 반면 Basic 인증에서는 토큰이 아니라 ID, PW 자체를 API 요청마다 Authorization header에 담아서 인증을 한다.
• 당연히 ID, PW 를 헤더에 plainText 로 넣게 되면, 보안에 취약하기 때문에 Base64 방식으로 ID및 PW를 아래와 같이 암호화한다.

//양식
Authorization: Basic Base64Encoded("ID:PW")

//예시
Authorization: Basic Base64Encoded("abc:qwe123")

//실제값
Authorization: Basic YWJjOnF3ZTEyMw==

• 해당 방식으로 HTTP Request 를 보낼 때 HTTP 헤더에 Authorization 키 값과 Basic YWJjOnF3ZTEyMw== 값을 보내면 되는 것이다.
• 그러나 Base64 방식으로 암호화하는 것은 말이 암호화지, 복호화가 굉장히 간단하기에 평문과 다를 게 없다.
  • https://www.base64decode.org/ko/
  • 같은 base64 형식 데이터를 디코딩하는 사이트에 들어가서 암호문을 입력하면 곧바로 평문을 따라서 획득할 수 있다.
• 그렇기에 Basic 인증 방식으로 HTTP 요청을 보낼 때 HTTPS/TLS를 사용해 http 요청의 보안을 향상해야한다.

1) 장점

• 간단함
  • ID, PW 외에 별도의 인증 정보를 요구하지 않는다.
  • 단순하고 구축하기 쉬움
• 보편성
  • 다양한 클라이언트 - 서버에서 사용되는 일반적인 인증 방식이다.
  • 다양한 환경에서 쉽게 구현할 수 있다.
  • 별도의 라이브러리가 필요 없으며, HTTP 표준의 일부로 포함되어있다.

2) 단점

• 서버 측 부담
  • 서버 측에서 사용자 목록을 저장해야 한다.
    • ID, PW 정보가 옳은 지 검토해야하기 때문.
  • 사용자가 많거나, 사용자 변화가 잦은 서비스에서는 OAuth 인증 방식을 택하는 것이 좋다.
• 사용자 권한 관리 부실
  • Basic 인증 방식으로 사용자 권한을 세세하게 설정하려면, 추가 구현이 필요하다.

---

• 참조:
  • https://www.ssemi.net/basic-authentication/
  • https://velog.io/@tosspayments/Basic-인증과-Bearer-인증의-모든-것

---

#3. 오늘의 회고

• 정리:
  • Basic 인증은 HTTP 프로토콜을 통해 사용자의 자격 증명을 전달하는 간단한 인증 방법 중 하나다.
  • ID, PW 만으로 사용자 인증을 할 수 있는 우리에게 친숙한 전통적인 방식이라고 볼 수 있다.
  • 그만큼 간단하고, 보편한 방식이라는 장점이 있는 반면에, 오래된 만큼 보안과 세세한 권한 관리에서 부족한 점이 많다.
    • 따라서 크고 신뢰성이 중요한 서비스일 수록 해당 방식을 택하지 않거나, 해당 방식에서 다른 방식으로 업그레이드를 한다.