오늘은
항해99의 1주차가 마무리 되었다. 솔직히 많이 아쉬운 일주일이었다 비전공자에 기초지식도 많이 없었기에 생소한 단어도 많았고 무엇보다도 알지못해 물어볼 수 조차 없는 부분도 많았다.. 주특기를 프론트엔드(리엑트)로 정하긴 했지만 아직까지도 별로 자신이 없고 주위 사람들을 보면서 많이 위축되기도 하는 것 같았다. 이게뭘까? 왜? 라는 생각은 매순간마다 찾아오지만 설명을 들어도 이해가지 않는 부분이 많았다 지나고나서 후회해봐야 소용없지만 '더 잘할 수 있었고 더 필사적으로 노력했으면 더 많은 것을 이해하고 얻어갈 수 있었을텐데 왜 그러지 못했지'라는 생각이 이제서야 드는 것 같다. 이번주차를 반성하는 계기로 생각하고 다음주에는 더 발전하는 내가 될 수 있도록 노력해야겠다.
JWT,세션/쿠키 방식
*세션/쿠키
-이 방식은 세션 저장소를 필요로하는데 저장소는 사용자가 로그인을 했을 때 사용자의 정보를 저장하고 열쇠가 되는 세션ID값을 만들어서 HTTP헤더에 실어 사용자에게 돌려보내는 방식이다.
(쿠키는 세션ID값이라 생각하면 이해가 편한 것 같다.)
*JWT방식
JWT는 JSON WEB TOKEN의 줄임말로 JSON을 사용해 정보를 안전하게 전달해주는 웹의 표준이다.
-인증에 필요한 정보들을 암호화시킨 TOKEN을 뜻 한다.
-TOKEN을 만드는데는 Header, Payload, Verify Signature이 3가지가 필요하다
-Payload,Header는 인코딩만 될 뿐이고 암호화가 되지않는다고 한다 그래서 SECRET KEY가 필요한 것 이고 Verify Signature은 SECRET KEY가 없으면 복호화할 수 없다. 또 SECRET KEY가 없다면 누구나 Payload에 담긴 정보를 디코딩하여 훔쳐갈 수 있다.
*내가 이해한 JWT
사용자가 로그인을 하면 계정정보를 읽어 사용자를 확인한 후 사용자에게 고유ID값을 부여한다.
사용자의 정보와 함께 Payload에 넣고 JWT의 유효기간을 설정해준다.
암호화할SECRET KEY를 이용해 TOKEN을 발급한다 사용자는 TOKEN을 받아 저장하고 인증이 필요할 요청마다 토큰을 헤더에 실어보내준다.
서버에서 헤더에서 받아온 TOKEN을 받아 Verifysignature을 SECRET KEY로 복호화한 후, 조작 여부, 유효시간을 확인하고 검증이 완료된다면 Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다.
*JWT장점/단점
-장점-
1. 간편하다.
2. Token을 발급 후 검증만하면 되기 때문에 세션/쿠키방식처럼 세션 저장소가 필요 없으므로
확장성이 좋다.
-단점-
1. Payload는 암호화되지 않기때문에 중요한 정보를 담을 수 없다 그러므로 Payload에 들어가는 정보는 제한적일 수 밖에 없다.
2. 발급된 JWT를 돌이킬 수 없다 세션/쿠키 방식은 쿠키가 악용될 경우 세션을 지우면 그만이지만 JWT방식은 유효기간이 만료될 때 까지 지켜볼 수 밖에없다.
API
사실 시간이 부족해서 API에 대해 정확한 공부를 하지 못해서 API가 무엇이며 어떤 역할을 하는지 정도만 알아보았다.
API는 프로그램들이 서로 상호작용을 하도록 도와주는 매개체이며
사용자의 정보가 담긴 데이터베이스를 허용된 사람에게만 접근성을 부여하는 역할을한다.또, 애플리케이션과 기기가 통신하고 데이터를 주고 받을 수 있도록 도와준다.
API 유형
다음주는 알고리즘 공부와 코딩테스트 공부를 시작해야한다 팀도 새로 배정될 것이고 개인 과제도 있을 예정이라한다. 멘탈 잘 잡고 열심히 최선을 다하자라는 생각으로 임해야겠다..