21.09.14 TIL

항해99 DAY 2

jinja2
flask에 내장되어 있는 Python 용 웹 템플릿 엔진.
서버 쪽에서 템플릿 HTML에 데이터를 끼워넣어 완성된 형태의 HTML을 보내주는 방법, 즉 서버사이드 렌더링 방식을 구현할 수 있다.
python에서 render_template 메서드를 호출할 때 아규먼츠를 넣어주면
return render_template("detail.html", rows=rows)
템플릿에서 해당 아규먼츠를 사용할 수 있다.

    <ul id="gu-list">
        {% for row in rows %}
            {% set gu_name = row["MSRSTE_NM"] %}
            {% set gu_mise = row["IDEX_MVL"] %}
            {% if gu_mise>=40 %}
                <li>{{ gu_name }}: {{ gu_mise|int }}</li>
            {% endif %}
        {% endfor %}
    </ul>

JWT
JSON Web Token의 줄임말로, JSON 객체를 사용해 정보를 안정성 있게 전달하는 웹표준

인증에 대하여 (참고 https://tansfil.tistory.com/58?category=255594)

서버에서는 데이터가 유출되는 상황을 피하기 위해 요청을 받았을 때 누구의 요청인지를 정확히 알아야 한다.
클라이언트에서는 요청과 함께 자신이 누구인지를 알만한 단서를 서버에 보내야 하며(보통 모바일/웹 서비스의 인증은 HTTP 메세지의 헤더에 인증 수단을 넣어 요청을 보내게 된다.)
서버는 그 단서를 파악해 각 요청에 맞는 데이터를 반환한다.

1. 매번 요청마다 계정정보를 요청 헤더에 넣는 방식
   최악의 보안성으로 테스트할때 정도에만 쓴다.

2. Session / Cookie 방식
   세션/쿠키 방식은 세션 저장소를 필요로 하며 세션 저장소는 사용자가 로그인을 했을 때 사용자의 정보를 저장하고 열쇠가 되는 세션ID값을 만든다. 그리고 세션ID를 HTTP 헤더에 실어 사용자에게 돌려보낸다. 그러면 사용자는 쿠키로 보관하고 있다가 요청에 쿠키(세션ID)를 넣어서 인증을 요청한다.
   다시 웹 서버에서는 세션 저장소에서 쿠키(세션ID)를 받고 저장되어 있는 정보와 매칭시켜 인증을 완료한다.

   

   1. 사용자가 로그인을 한다.
   2. 서버에서는 계정정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID값을 부여하여 세션 저장소(보통 redis)에 저장한 후, 이와 연결되는 세션ID를 발행한다.
   3. 사용자는 서버에서 해당 세션ID를 받아 쿠키에 저장을 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보낸다.
   4. 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져온다.
   5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내준다.

   (장점)
   쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID)는 유의미한 값을 갖고있지 않기 때문에 계정정보를 담아 인증을 거치는 것보다는 안전하다.
   서버에서는 쿠키 값을 받았을 때 일일이 회원정보를 확인할 필요 없이 바로 어떤 회원인지를 확인할 수 있다. (아마도 DB까지 안가고 세션저장소에서 유저 정보를 확인할 수 있다는 말인것 같다.)

   (단점)
   HTTP 요청을 가로챘다면 그 안에 들어있는 쿠키도 충분히 훔칠 수 있다. 그리고 훔친 쿠키를 이용해 HTTP 요청을 보내면 서버의 세션저장소에서는 정보를 노출한다.(세션 하이재킹 공격)
   -> HTTPS를 사용해 요청 자체를 탈취해도 안의 정보를 읽기 힘들게 한다, 또는 세션에 유효시간을 넣어준다.
   세션 저장소를 사용하므로 서버에서 추가적인 자원사용량을 필요로 한다.

3. 토큰 기반 인증 방식 (JWT)
   JWT는 Json Web Token의 약자로 인증에 필요한 정보들을 암호화시킨 토큰을 뜻한다. 위의 세션/쿠키 방식과 유사하게 사용자는 Access Token(JWT 토큰)을 HTTP 헤더에 실어 서버로 보낸다.
   https://jwt.io/ 에서 쉽게 토큰을 인코딩/디코딩 해볼 수 있다.

   토큰의 3 요소
   Header : 토큰의 암호화 방식(alg), 타입(type) 등
   Payload : 서버에서 보낼 데이터. 일반적으로 유저의 고유 ID값, 유효기간.
   Verify Signature : Base64 방식으로 인코딩한 Header,payload 그리고 SECRET KEY를 더한 후 서명된다.
   (Verify Signature는 SECRET KEY를 알지 못하면 복호화할 수 없으므로 JWT 보안의 핵심이다.)
   최종적인 결과 : Encoded Header + "." + Encoded Payload + "." + Verify Signature

   

   1. 사용자가 로그인을 한다.
   2. 서버에서는 계정정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여한 후, 기타 정보와 함께 Payload에 넣는다.
   3. JWT 토큰의 유효기간을 설정
   4. 암호화할 SECRET KEY를 이용해 ACCESS TOKEN을 발급
   5. 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 헤더에 토큰을 넣는다.
   6. 서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효기간을 확인
   7. 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 전달

   세션/쿠키 방식과 가장 큰 차이점은 JWT는 세션 저장소 없이 토큰 안에 유저의 정보들이 넣는다는 점이다. 물론 클라이언트 입장에서는 HTTP 헤더에 세션ID나 토큰을 실어서 보내준다는 점에서는 동일하나, 서버 측에서는 인증을 위해 암호화를 하냐, 별도의 저장소를 이용하냐는 차이가 발생한다.

   (장점)
   JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없다. 이는 Stateless 한 서버를 만드는 입장에서는 큰 강점이다.
   (Stateless는 어떠한 별도의 저장소도 사용하지 않는, 즉 상태를 저장하지 않는 것. 이는 서버를 확장하거나 유지,보수하는데 유리하다.)
   토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하기 때문에 확장성이 뛰어나다. (ex) Facebook 로그인, Google 로그인

   (단점)
   이미 발급된 JWT에 대해서는 돌이킬 수 없다. 세션/쿠키의 경우 만일 쿠키가 악의적으로 이용된다면, 해당하는 세션을 지워버리면 되지만 JWT는 한 번 발급되면 유효기간이 완료될 때 까지는 사용이 가능하다.
   -> 기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급한다. 그렇게 되면 Access Token을 탈취당해도 상대적으로 피해를 줄일 수 있습니다.
   유저의 중요한 정보들은 Payload에 넣을 수 없기 때문에 Payload 정보가 제한적이다.
   토큰은 세션/쿠키 방식에 비해 길다.