- JWT (JSON Web Token)
서버가 클라이언트 인증을 확인하는 방식중 하나 (쿠키,세션,토큰 방식이있다)
토큰 기반 인증 시스템은 클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로
'토큰'을 부여한다. 그중에서도 JWT(JSON Web Token)은
인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다.
JWT 기반 인증은 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식이다.
JWT는 JSON 데이터를 Base64 URL-safe Encode 를 통해 인코딩하여 직렬화한 것이며,
토큰 내부에는 위변조 방지를 위해 개인키를 통한 전자서명도 들어있다.
사용자가 JWT 를 서버로 전송하면 서버는 서명을 검증하는 과정을 거치게 되며 검증이 완료되면 요청한 응답을 돌려준다.
구조
JWT는 . 을 구분자로 나누어지는 세 가지 문자열의 조합이다.
. 을 기준으로 좌측부터 Header, Payload, Signature를 의미한다.
장점
- Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
- 인증 정보에 대한 별도의 저장소가 필요없다.
- JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됬음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
- 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태(StateLess)가 되어 서버 확장성이 우수해질 수 있다.
- 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다. (쿠키와 차이)
- OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
- 모바일 어플리케이션 환경에서도 잘 동작한다. (모바일은 세션 사용 불가능)
단점
- Self-contained : 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다.
- 토큰 길이 : 토큰의 Payload에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다.
- Payload 인코딩 : payload 자체는 암호화 된 것이 아니라 BASE64로 인코딩 된 것이기 때문에, 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, payload에 중요 데이터를 넣지 않아야 한다.
- Store Token : stateless 특징을 가지기 때문에, 토큰은 클라이언트 측에서 관리하고 저장한다. 때문에 토큰 자체를 탈취당하면 대처하기가 어렵게 된다.
다만 이 JWT도 제 3자에게 토큰 탈취의 위험성이 있기 때문에, 그대로 사용하는것이 아닌 Access Token, Refresh Token 으로 이중으로 나누어 인증을 하는 방식을 현업에선 취한다.
- API
API는 Application Programming Interface(애플리케이션 프로그램 인터페이스)
API를 사용하면 구현 방식을 알지 못하는 제품 또는 서비스와도 통신할 수 있으며 애플리케이션 개발을 간소화하여 시간과 비용을 절약할 수 있습니다. 새로운 툴과 제품을 설계하거나 기존 툴과 제품을 관리할 때 API를 사용하면 유연성을 높이고 설계, 관리,
사용 방법을 간소화하며 혁신의 기회를 얻을 수 있습니다.
API는 당사자들 간 계약을 나타내는 도큐멘테이션을 갖춘 계약으로 비유되기도 합니다. 한쪽 당사자가 특정한 방식으로 구성된 원격 요청을 보내면 다른 쪽 당사자의 소프트웨어가 이에 응답하는 방식이기 때문입니다.
API는 개발자가 새로운 애플리케이션 구성 요소를 기존 아키텍처에 통합하는 방식을 간소화하므로 비즈니스 팀과 IT 팀의 협업에도 도움이 됩니다.
디지털 시장은 새로운 경쟁 기업이 새로운 애플리케이션과 함께 등장하여 업계 전체의 판도를 바꾸기도 하는 등 끊임없이 변화할 수밖에 없으므로, 이에 대응해 비즈니스 요구사항도 빠르게 변화하는 경우가 많습니다. 따라서 경쟁력을 유지하려면 혁신적인 서비스를 신속하게 개발하고 배포하도록 지원해야 합니다. 클라우드 네이티브 애플리케이션 개발은 개발 속도를 높이기 위한 식별 가능한 방식이며, API를 통한 마이크로서비스 애플리케이션 아키텍처 연결에 기반합니다.
API는 클라우드 네이티브 애플리케이션 개발을 통해 자체 인프라를 연결하는 간소화된 방식이지만, 고객 및 다른 외부 사용자와의 데이터 공유를 허용하기도 합니다. 퍼블릭 API는 파트너와의 연결 방식을 간소화하고 확대할 수 있을 뿐만 아니라 보유한 데이터를 활용해 수익을 창출할 수 있기 때문에 고유의 비즈니스 가치를 지닙니다(예: Google Maps API).
[다시 정리하고싶다]
- 첫 항해를 시작하고 이번주에 배운 점, 느낀 점
배운점 : .....................여러가지 기술들을 정리하고 차근차근 습득할수있는 시간을 주지않아......그냥때려넣어...막넣어..
그래서 여러가지를 배웠는데 혼미해짐..기억안남..엄청배움...
느낀 점 : 버겁다? 정말 비전공자가 패기와 열정만 가지고 버티기에 버겁다 ? 분명 1주차에 한번씩 무너지지않을까?
내 멘탈은 내가잡아야지 . 동기들을 붙잡고 물어보고 기술매니저님께 붙잡고 물어보고 열심히 귀동냥하고 집어넣는느낌.
......................원래 좋고 유익한내용을 차근히 정리하고싶었으나 ........시간이 없어서...지금 당장생각나는.
단순한 느낌과 막막함만 적어 넣는게 아쉽다 ...문제풀이/ 영상시청 / 개념정리 이제 스터디까지 추가됐으니...15시간 갈아넣는
지금도 시간이 부족하고 슬픈데 ㅠ_ㅠ...........나 어쩌냐..............그래도 계속쌓고 넣고 포기하지않으면 눈이 트이겠지
그날이 오길 기다리며 / 제출 마감기한을 넘긴 WIL을 남기고 넘겨본다.
인생과 직업을 바꾸는 일이니 쉽지않고 단기간에 이루려면 내자신의 최대치의 노력을 갈아넣어야 한다.
주말도 당연 내것이아니며 쉬는날에도 따라가지못하는 나에게 계속 강의와 개념을 잡아간다.
남들보다 진도가 느리다. 하지만 비교하지않겠다. 우등생이있으면 열등생이있는거고. 계속끝까지 열등생으로 남지않으리라.
'개발일지. > 항해99' 카테고리의 다른 글
| 주특기 기본주차 팀과제1 (0) | 2022.11.26 |
|---|---|
| 항해99 2주차 알고리즘 본시험 TIL (22.11.25) (0) | 2022.11.26 |
| 항해99 2주차 주특기 과제 (2.실습과제) (0) | 2022.11.18 |
| 항해99 2주차 주특기 과제 (1.설명하기) (0) | 2022.11.18 |
| 1주차 풀스텍 프로젝트 TIL (22.11.14) (0) | 2022.11.16 |