#클라이언트 인증 (http 기본 인증)

http는 기본적으로 stateless (무상태)이다. stateless라서 세션을 유지하기 위해서 쿠기 메커니즘을 사용한다.

하지만 안드로이드나 IOS기기 또는 CURL 등 다양한 클라이언트들이 쿠키 메커니즘이 동작한다고 보장 할 수 없다.

세션을 유지하지 않고, 요청할 떄마다 인증 정보를 제시하고 사용자를 식별하면 된다.

서버에 요청할 때마다 Authorization 요청 헤더에 인증 정보를 담아서 보낸다. 

1. http 기본 인증 

Header : POST /v1/articles HTTP/1.1
HOST : localhost
Authiruzation : Basic 12389sfdjiookasdy9849sdui== -- base61_encode
Accept : application/json
Content-Type : application/json 

{ "title":"글",
  "content":"몰라요"
}


- 기본 인증의 한계 (여러 가지 보안 취약점을 가지고 있다.)

1. 아이디와 비밀번호를 클라이언트 애플리케이션에 저장해야 한다. 
   개인 컴퓨터면 문제가 되지 않지만 공용 기기라면 완전히 다른 얘기가 된다. 

2. 평문으로 되어 있다.
   네트워크단에서 탈취 할 수도 있다. 다른 네트워크 도구 뿐 아니라, 브라우저의 개발자 도구로도 헤더를 볼수 있다. 

* 암호화가 가능 ,https 프로토콜을 이용하여 해결 가능 , 인트라넷처럼 제한된 환경에서 http 기본 인증 가능



#JWT
클라이언트 서버
1.CreateToken{ID:xx PW:xx} ----------------------------------------> 2. Token 생성 및 Store (저장)
        4. Tocken 저장      <----------------------------------------- 3.  tocken 
5.  Authorization 요청 헤더에 토큰을 달아서 보낸다(API호출 등) ----> 6. 유효성 확인 후 결과 전송 ( API 응답 , 로그인 등) 
7.  result                      <----------------------------------------  result

* 60 ~ 120분 적당(?)

#cors 동일 출처 보안 정책 (브라우저에서 이를 막음)
SPA ex) react 3000 port --> node 5000 port 

기본적으로 프로토콜,호스트명,포트 아 같은 Same-Origin에서의 접근이 가능하지만 다른 도메인
Adomain.page1.html -> Adomain.page2.html   Same-Origin

Adomain.page.html  -> Bdomain.page.html     Cross-Origin

서버에서 허용하여 주는 것으로 해결



# 보안 정책
1.사용량 제한

    특정 클라이언트가 API를 과도하게 사용하면 다른 클라이언트가 피해를 본다. 그뿐만 아니라 사용량 제한은 디도스 공격, 사전 공격 등으로부터 서비스를 보호하기도 한다.
    그래서 지정한 시간 동안 요청할 수 있는 횟수를 제한하는 방법 

2.리소스 아이디 난독화

    auto_increment를 기본키로 사용할 경우, 서비스가 커지면 자동 증가 아이디도 공격의 대상이 될 수 있다. 

-API로 응답받은 리소스의 아이디로 다른 리소스를 탐색 할 수 있다, 하지만 인증이나 인가 기능이 막아준다.
-아이디 번호를 하나씩 올려가며 리소스 전체를 긁어 갈 수 있다.
-사용자 아이디를 하나씩 올려 가며 서비스의 전체 사용자 수를 예측할 수 있다.

UUID를 사용하거나, 난수를 사용한다 

+ Recent posts