항해99 1주차 WIL - 처음 만든 웹페이지 공유, JWT, API, 로그인 방식 구현하는 법

728x90

항해99를 처음 시작한 날, 첫 시작날 두근두근 설레임이었는데 청천벽력을 들었다.

첫 날인데,,, 분명 첫 날인데! 갑자기 웹사이트를 만드는 프로젝트가 주어졌고 참고할 수 있을 정도의 강의만 제공된 후 팀 프로젝트가 시작되었다.

기한은 월~목, 단 4일 이라서 망했다 싶었다.

결국 하루에 최소 12시간 ~ 15시간씩 항해99에만 투자했고(물론 점심시간, 저녁시간, 쉬는시간도 가지긴 했지만 그 외 모든 시간을..) 완성할 수 있었다!!

첫번째 우리 팀이 함께 만든 댕미팅 프로젝트❤️ // 도메인은 수정할 거라 영상 남기기!

우리팀의 주제는!!! 댕미팅!!!

바로 강아지들의 소개팅이다!

팀원중 성*님의 아이디어로 시작된 강아지들의 소개팅 웹사이트로 구현하고자 한 것은 아래와 같다.

⭕ 해낸것!

1️⃣ 시작페이지 - 로그인, 로그아웃, 회원가입기능

1) 아이디 중복여부 확인 기능

2) 비밀번호 숫자, 특수문자, 자리수 확인 기능

3) 회원가입 완료되면 메인 페이지로 넘어가는 기능

4) 로그인이 완료되면 다음 페이지로 넘어가는 기능

2️⃣ 메인 페이지 - 상단 navbar 추가, 프로필 등록기능 등

1) 프로필 사진 첨부파일 추가 기능

2) option, input 등 작성 및 선택 기능

3) 작성한 프로필을 붙여넣는 기능

4) 내 프로필을 아래 카드에 붙여넣는 기능 - temp_html~~

5) 카드 구현 기능

6) robo3T를 통해 DB를 저장하는 기능

7) sourcetree를 통해 GitHub에 파이썬, html, css 파일 추가하는 기능

8) AWS를 통해 저장한 DB를 가져오는 기능

9) Filezilla를 통해 도메인에 집어넣는 기능

❌ 해결하지 못한 것

1️⃣ API 설계

기술매니저님이 API 설계하고 시작해야 다른 길로 빠지지 않을 수 있고 코드의 오류가 없다고 하셨는데, API를 도대체 어떻게 설계해야 하는 건지 어려워서 결국 API설계 없이 하나하나 시작되었다.

2️⃣ GitHub 올리는 법

팀원 4명이서 프로젝트를 나눠서 해야 효율적으로 할 수 있는데, 어떻게 하면 충돌없이 올릴 수 있는지, 올린 것을 어떻게 봐야 하는건지 어려워서 맨 마지막에 한번에 올리게 되었다.

위 두 가지는 반드시 알고 넘어가야 할 것 같다 ㅠㅡㅠ 이 방법에 대한 건 강의가 있으면 좋겠는데,,,,,GitHub 강의는 있긴 해서 사용법은 알겠는데 현장에서 어떻게 써야하는지 쪼끔 어렵다..구글링해도 잘 모르겠다.. 그래도 더 찾아보자! 이렇게 해낼 수 있겠지..!!

그래서 WIL 쓰는 김에, 그리고 이번주의 키워드가 JWT와 API인 김에 정의부터 차근차근 다시 익혀서 넘어가보자!

[복습겸 참고한 강의]

👌 API 정의 - 웹개발 플러스 1주차 4강

✅ API란?

- 서버가 요청을 받게 하기 위해 뚫어놓은 '창구'

- 요청에는 POST, GET 처럼 여러가지 타입이 있다.

1) POST : 주로 데이터를 '수정'할 때

2) GET : 주로 데이터를 '가져올' 때

👌 JWT 정의 - 웹개팔 플러스 4주차 4강

나는 오늘 JWT에 대해 적을 거고, 이 방식으로 위에 '댕미팅 프로젝트'를 마무리했는데, JWT를 공부하기 전에는 다른 방식도 볼 필요가 있다.

❓ 인증이 왜 필요할까?

'프론트엔드' 관점에서 보면 :
사용자의 로그인, 회원가입과 같이 사용자의 '도입 부분'을 가리키곤 한다.

'서버사이드' 관점에서 보면 :
모든 API 요청에 대해 사용자를 확인하는 작업이다.

'프론트엔드' + '서버사이드' : 사용자 A와 B가 있는데 누구의 요청인지 정확히 알지 못한다면, 회원의 정보가 타인에게 유출되는 최악의 상황이 발생할 수 있기 때문에, '프론트엔드'에서는 자신이 누구인지를 알만한 '단서'를 '서버'에 보내야 하며, '서버'는 그 단서를 '파악'해 각 요청에 맞는 '데이터'를 뿌려주게 된다.

- 회원임을 인증하는 방식은 3가지로 볼 수 있다.

1) 계정 정보를 요청 헤더에 넣는 방식

2) Session / Cookie 방식

3) JWT 방식

1️⃣ 계정 정보를 요청 헤더에 넣는 방식

- 정의 : 계정정보를 HTTP 요청에 인증할 수단에 비밀번호를 넣는 방식 // 최악의 인증방식이다. 데이터를 요청할 때마다 사용자의 프라이빗한 정보를 '계속해서' 보낸다는 것은 보안에 안좋기때문! 보통 앱에서는 '서버'로 'HTTP 요청'을 할 때, 따로 암호화하지 않기 때문에 해커가 마음만 먹으면 'HTTP 요청'을 가로채서(intercept) 사용자의 계정정보를 알 수 있다.

1) 장점 : 인증을 테스트 할 때 빠르게 시도해볼 수 있다. 실제 서비스에서는 쓰이지 않고 개발 단계에서 인증절차가 귀찮을 때에나 쓸만한 정도

2) 단점 : 보안에 매우 취약하며, '서버'에서는 '신호'가 올 때마다, Id, Pw를 통해 유저가 맞는지 인증해야 한다. 이래서 비효율적이다.

이러한 보안에 취약한 특징 때문에 나온 인증 방식이 바로 [Session / Cookie 방식]이다!

2️⃣ Session / Cookie 방식

❓ 순서가 뭘까?

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

❓ 필요한 것은?

1. 세션 저장소 // Redis를 많이 사용한다.
🕶️ 로그인을 했을 때, 사용자의 정보를 '저장'하고 열쇠가 되는 '세션ID'값을 만든다.
🕶️ 세션ID를 만든 후 'HTTP 헤더'에 실어서 사용자에게 돌려보낸다.
🕶️ 사용자는 '쿠키'로 보관하고 있다 인증이 필요한 요청에 쿠키(세션ID)를 넣어 보낸다.🕶️ '웹 서버'에서는 세션 저장소에서 쿠키(세션ID)를 받고 저장되어 있는 정보와 매칭시켜 인증을 완료한다.

세션ID = 쿠키 라고 봐도 동일하다.

쿠키가 사용자 개념에서는 더 큰 범주 // 세션 ID를 쿠키로 저장하는 셈

세션 : 서버에서 가지고 있는 정보 // 쿠키 : 사용자에게 발급된 세션을 열기 위한 열쇠(세션 ID)

⭕ 장점 :

🔹 쿠키가 담긴 HTTP 요청이 노출되더라도, 쿠키 자체(세션 ID)는 유의미한 값을 갖고 있지 않기 때문에(중요한 정보는 서버 세션에 있다), 위의 계정 정보를 담아 인증을 거치는 것보단 안전하다.

🔹 사용자 A는 1번, B는 2번 이런식으로 '고유의 ID'값을 발급받게 되는데, 서버에서는 쿠키 값을 받았을 때 일일이 회원 정보를 확인할 필요가 없어지기 때문에 서버의 자원에 접근하기 용이하다.

❌ 단점 :

🔹 장점 1에 보면 HTTP 요청이 노출되도 안전하다고 했으나, 해커는 HTTP 요청 안에 있는 '쿠키'를 충분히 훔칠 수는 있다. 만약 B사용자에게 이 훔친 쿠키를 주고 이용해서 HTTP 요청을 보내면 서버의 세션 저장소에서는 A 사용자라고 오인해서 정보를 잘못 뿌려줄 수 있다 // 이걸 '세션 하이재킹 공격' 이라고 한다.

// 해결 방법 : HTTP를 사용해 요청 자체를 탈취해도 안의 정보를 읽기 힘들게 만든다, 세션에 유효시간을 넣어준다

🔹 서버에서 세션 저장소를 사용한다고 했는데, 그러다보니 서버에서는 추가적인 저장 공간을 필요로 하게 되고 자연스럽게 부하도 높아진다.

3️⃣ JWT란?

- 정의 : JSON Web Token의 줄임말로, JSON 객체를 사용해 정보를 안정성 있게 전달하는 웹표준 // (외국에서는 JOT로도 읽는다)

- 예시

1) 로그인 기능 : 사용자가 '로그인'을 하면, '서버'에서 회원임을 인증하는 '토큰'을 넘겨줌으로써 이후 '회원만' 접근할 수 있는 서비스 영역에서 신분을 확인하는데 쓰일 수 있다.

✅ '토큰' 기반 '인증' 방식 "JWT"

❗ JWT , 세션/쿠키 : 모바일, 웹의 인증을 책임지는 대표 주자

❗ '인증'에 필요한 '정보'들을 '암호화'시킨 '토큰'이다.

❗ [세션/쿠키] 방식과 유사하게 사용자는 'Access Token[JWT 토큰]'을 'HTTP 헤더'에 실어 '서버'로 보내게 된다.

❓ 필요한 것은?

1. Header : 이 3가지 정보를 암호화 할 방식(alg), 타입(type) 등이 들어간다.
2. Payload : '서버'에서 보낼 데이터가 들어간다. 일반적으로 유저의 '고유ID값', '유효기간'등이 들어간다.
3. Verify Signature : Base64 방식으로 인코딩한 Header, payload 그리고 SECRET KEY를 더한 후 서명된다.

❓ 순서

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

❓ Session/Cookie 방식과 JWT와의 차이점은??

🔹 Session/Cookie 방식 : 별도의 저장소 관리가 필요하다.

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

⭕ 장점 :

🔹 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요 없다. Stateless한 서버를 만드는 입장에서 큰 강점이다. Stateless란, 어떠한 별도의 저장서도 사용하지 않는 즉, 상태를 저장하지 않는 것을 의미한다. 서버를 확장하거나 유지, 보수하는데 유리하다.

🔹 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하다

// 예시 : Facebook 로그인, Google 로그인 등은 모두 토큰 기반으로 인증을 한다. 이에 선택적으로 이름이나 이메일 등을 받을 수 있는 권한도 받을 수 있다.

❌ 단점 :

🔹 1) 이미 발급된 JWT 에 대해서 돌이킬 수 없다. Session/Cookie 방식의 경우 쿠키가 악의적으로 이용된다면, 해당 세션을 지워버리면 되는데, JWT는 한 번 발급되면 '유효기간'이 완료될 때까지 계속 사용이 가능해서, 악의적인 사용자는 유효기간이 지나기 전까지 신나게 정보를 털어갈 수 있다.....

// 해결 방법 : 기존의 Access Token의 유효기간을 짧게 하고 Refresh Token이라는 새로운 토큰을 발급한다. 그렇게 되면 상대적으로 피해를 줄일 수 있다.

🔹Payload 정보가 제한적이다. Payload는 따로 암호화하지 않기 때문에, 디코딩하면 누구나 정보를 확인할 수 있다. Session/Cookie 방식에서는 유저의 정보가 전부 서버의 저장소에 안전하게 보관되었다. 따라서 유저의 정보를 Payload에 넣을수 없다.

🔹 Session/Cookie 방식에 비해 JWT의 길이는 길다. 따라서 인증이 필요한 요청이 많아질 수록 서버의 자원낭비가 발생된다.

👌 플라스크 서버에서 로그인 기능 구현하기!

1) 로그인 시, 비밀번호를 같은 방법으로 '암호화'한 후, DB에서 해당 아이디와 비밀번호를 갖는 회원이 있는지 찾는다. 회원 정보가 없는 경우 실패 메시지를 보내고, 찾은 경우 아이디와 '토큰 만료 시간'을 보내는 토큰을 만들어 넘겨준다.

2) 로그인 성공 메시지를 받으면, 건네받은 토큰을 쿠키로 저장하여 만료되기 전까지 갖고 있으면서, API 요청을 보낼 때마다 회원임을 확인 받는다.

3) 로그아웃 시 해당 토큰을 삭제한다.

솔직히 아직 무슨말인지 모르겠다!

그래도 '댕미팅 프로젝트'하면서 로그인 페이지를 만들어보았기 때문에, 충분히 참고할 만한 베이스가 생겼다.

app.py

0.01MB

댕미팅 프로젝트할 때, 강의를 따라하며 CSS를 추가하여 내가 만든 로그인 파일이다.

CSS 파일은 따로 올리지 않고 방법만 확인하려고 참고차 올린다.

초반 출처 : 강의 참고

중간 출처 : 더 깊게 알아보려면 : https://tansfil.tistory.com/58?category=255594 // 4주차 강사님이 올려주신 링크