호비시의 끄적끄적
JWT 인증방식 본문
JWT
로그인 기능을 구현 하기 위해서 클라이언트가 서버에 자신의 정보를 전달 해 주어야 한다.
그래야 누가 접속을 하는 지 서버가 파악하고 유저에 맞춰 정보를 전달해 줄 수 있기 때문이다.
이런 과정에서 꼭 필요한 것이 인증 부분이다.
HTTP 통신을 함에 따라 클라이언트는 서버에 HTTP 메시지를 보낸다.
HTTP는 헤더, 바디 로 구성되며 바디에는 서버로 보내야 할 데이터, 헤더에는 웹 서비스의 인증 수단을 넣어서 보낸다.
인증 방식에는 여러가지가 있다.
1. 계정정보를 헤더에 넣는 방식
HTTP 요청을 할 때 클라이언트가 입력한 data를 헤더에 직접 넣어서 보내는 방식이다.
보안에 매우 취약하여 절대 사용하지 않는 방식으로, 개발단계에서 쓰입니다.
장점
인증 테스트할 때 빠르게 시도 가능
단점
보안에 취약
서버에 신호가 올 때 마다 비효율적으로 id pw 체크를 해야한다.
2. SESSION COOKIE
계정정보를 헤더에 매번 넣어 보내기엔 보안이 너무 취약하므로 서버와 클라이언트에 KEY값을 일시적으로 저장하여 비교하는 방식이다.
장점
1. HTTP 요청 중에 쿠키를 탈취 당하더라도 쿠키 자체는 의미 있는 값이 아니기 때문에 HTTP 헤더에 정보를 넣는 것 보다는 안전.
2. 고유의 ID를 가지기 때문에 회원정보를 확인할 필요 없이 서버에 접근할 수 있다.
단점
1. 만약 A의 쿠키를 탈취해 HTTP요청을 보내면 A 로 착각해 접근 할 수 있습니다.
-> 세션에 유효시간을 넣어서 해결 할 수 있다.
2. 서버에 세션 값을 저장해야하기 때문에 서버에 부담이 간다.
3. JWT
Json Web Token 인증에 필요한 정보들을 암호화 시킨것들을 토큰에 저장하는 것
Header . Payload . Signature 형태로 encoding 되어 저장됨
장점
1. 세션 쿠키에 비해 추가 저장소가 필요없어 관리가 간단함
2. 다른 인증시스템으로 확장이 뛰어남
단점
1. 이미 발급된 JWT에 대해서 돌이킬 수 없음. 악의적으로 사용하더라도 유효기간이 끝나기 전까지 계속 정보를 털어 갈 수 있음
-> 유효기간을 짧게 하여 해결 가능
2. 유저의 정보에 Payload 를 넣을 수 없기 때문에 정보가 제한적
3. JWT 길이가 길어서 자원낭비 할 수 있음
'알고리즘 > 이것저것' 카테고리의 다른 글
조합 (0) | 2023.07.05 |
---|---|
API (0) | 2022.03.13 |
java String 관련 함수 (0) | 2022.03.11 |