티스토리 뷰
1. 로그인 인증방식
1) 세션기반인증
- HTTP통신 -> 상태없음(stateless) 하다
- HTTP 요청을 통해 데이터를 주고 받을 때 요청이 끝나면 요청한 사용자의 정보 등을 유지하지 않는다.
- 로그인을 했을 때 로그인이 유지되지 않는다.
▶ 세션ID를 생성해서 쿠키에 저장하는 인증방식을 사용한다.
ⓛ 세션기반 로그인 프로세스
- 처음 로그인을 하면 세션ID가 생성
- 서버에서 세션ID를 쿠키로 설정해서 클라이언트에 전달
- 클라이언트가 서버에 요청을 보낼 때 해당 세션ID를 쿠키로 담아서 전에 로그인했던 아이디인지 확인
- 로그인을 유지
② 장점
- 서버에서 사용자의 로그인 상태확인을 하기 쉽다.
- 서버에서 세션정보를 담당하기 때문에 클라이언트가 정보를 변경하기 어렵다.
- 토큰과 달리 Signiture같이 추가되는 데이터가 없기 때문에 서버-클라이언트간 주고받는 데이터가 적다.
③ 단점
- 사용자 상태에 대한 정보를 서버에 저장하기 때문에 사용자가 많다면 서버에 과부하가 걸린다.
- RDBMS에 저장한다면 직렬화 및 역직렬화에 관한 오버헤드가 발생한다.
2) 토큰 기반 인증
- 토큰을 처리하는 한 서버를 두고 다른 컨텐츠를 제공하는 서버는 모두 stateless하게 만들자는 이론이 담긴 방식
- => 확장성이 좋다.
- 토큰을 관리하는 서버를 따로 두어야 한다.
▶ 도메인A와 토큰을 같은 서버에 두면 도메인A에 문제가 생겼을 경우 토큰에도 문제가 생겨 다른 도메인 기능도 연달아서 마비가 되기 때문에 토큰을 관리하는 서버는 따로 두어야 한다.
ⓛ 토큰기반 로그인 프로세스
1. 인증로직에 따라 로그인에 성공하면 JWT토큰생성된다.
2. 사용자가 이후에 access 토큰을 HTTP Header - Authorization 또는 HTTP Header - Cookie에 담아 인증이 필요한 서버에 요청해 원하는 컨텐츠를 가져온다.
② JWT토큰 ( JSON Web Token ) 구조
- Header : 토큰의 유형과 사용된 서명 알고리즘이 base64로 인코딩 된다.
- payload : 데이터, 토큰 발급자, 토큰 유효기간이 base64로 인코딩 된다.
- signiture : 인코딩된 header + payload + 비밀키를 헤더에 명시된 알고리즘으로 다시 생성한 서명값.
주의점
● https를 사용해야 한다.
● 쿠키에 저장한다면 sameSite: 'Strict'을 써야 한다.
● 수명이 짧은 access token을 발급한다.
● url에 토큰을 전달하면 안된다.
③ JWT 장점
- 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요없다.
- 다른 유형의 토큰과 비교했을 때 경량화되었다.
- SAML(Security Assertion Markup Language Tokens)이란 토큰이 있지만 이에 비해 훨씬 경량화되어있음.
- 디코딩했을 때 JSON이 나오기 때문에 JSON을 기반으로 쉽게 직렬화, 역직렬화가 가능하다.
④ JWT 단점
- 토큰이 비대해질 경우 당연히 서버과부화에 영향을 줄 수 있다.
- 토큰을 탈취당할 경우 디코딩했을 때 데이터를 볼 수 있다.
⑤ access token & refresh token
access token | refresh token | |
유효 기간 | 짧다 | 길다 |
사용 용도 | 자원에 접근위한 인증용도 | access token의 갱신, 세션관리 |
저장 위치 | 클라이언트의 임시저장소 | 안전한 장소 |
2. HTTP 상태코드 & 메서드
1) HTTP 상태코드
ⓛ 1xx
- 정보
- 서버가 요청을 잘 받았으며 해당 프로세스를 계속 이어가며 처리하는 것
상태코드 | 의미 |
100 | 진행중 |
② 2xx
- 성공
- 서버가 요청을 잘 받았고 이를 기반으로 클라이언트에게 성공적으로 데이터를 보낸 것
상태코드 | 의미 |
200 OK | 요청이 성공적 |
201 Created | 요청이 성공적이었으며 그 결과로 새로운 리소스가 생성됨 |
③ 3xx
- 리다이렉션
- 서버가 클라이언트의 요청에 대해 완료를 위해 추가 작업 조치가 필요하다.
상태코드 | 의미 |
301 Moved Permaently | 요청한 리소스의 URI가 변경됨 -> 변경된 새로운 URI을 301 상태코드와 함께 주어야한다. |
④ 4xx
- 클라이언트 오류
- 클라이언트가 요청한 페이지를 제공할 수 없거나 클라이언트의 요청이 잘못되어 결과적으로 요청을 처리할 수 없다.
상태코드 | 의미 |
400 Bad Request | 서버가 클라이언트 요청을 이해할수 없음 |
401 Unauthorized | 클라이언트의 인증이 되지 않음 |
404 Not Found | 요청받은 컨텐츠를 찾을 수 없음 |
⑤ 5xx (서버 오류)
- 서버가 클라이언트의 요청을 처리하지 못하는 상태입니다.
상태 | 의미 |
500 Internal Server Error | 서버에 오류가 있음 |
502 Bad Gateway | 게이트웨이 또는 프록시서버가 오류가 생겼음 |
504 Gateway Timeout | 게이트웨이 또는 프록시서버가 정해진 Timeout 시간동안 클라이언트의 요청을 처리하지 못함 |
2) HTTP 메소드
- 클라이언트와 서버 사이에 이루어지는 요청과 응답 데이터를 전송하는 방식
- 서버에 주어진 리소스에 수행하길 원하는 행동, 서버가 수행해야 할 동작을 지정하는 요청을 보내는 방법
★ 주요 메소드 ★
① GET : 데이터 조회
② POST : 데이터 생성,처리
③ PUT : 업데이트 데이터 전체 변경
④ PATCH : 업데이트 데이터 일부 변경
⑤ DELETE : 데이터 삭제
① GET
- 쿼리스트링을 기반으로 데이터를 요구한다.
- 길이제한 : 2000자 미만
- 요청 파라미터가 브라우저 기록에 남음 -> 민감한 정보전달시 사용하지 않음
- ASCII문자열만을 보낼 수 있음
GET /member/001?userid=aaa&username=bbb
- 성공시 HTTP 상태코드 : 200
- 캐싱 가능
- POST도 정보 조회가 가능하지만 GET은 캐싱도 가능해서 GET으로 조회하는게 유리함.
② POST
- HTTP message body를 통해 데이터를 전달
- 길이 제한 X
- 해당 요청의 파라미터가 브라우저기록에 남지 않는다.
- ASCII문자열 뿐만 아니라 모든 유형의 데이터를 요청가능하다.
- 민감한 정보를 전달할 때 사용한다.
- 성공적으로 데이터를 생성할 경우 HTTP 상태코드 201을 반환한다.
- 생성 : HTTP 상태코드 201
- 생성 X : HTTP 상태코드 200을 반환
- 캐싱 불가능
③ PUT
- 요청을 보낼 때 데이터 전체를 보내 전체 데이터 교체를 한다.
- 데이터가 있다면 덮어쓰고, 없으면 새로운 데이터로 교체한다.
- PUT 요청
// 데이터 있을 때 정보 변경
PUT/ member/001 http1.1 PUT/ member/001
content-type: text -> { "a" : 1, "b" : 2 }
{ "a" : 1, "b" : 3}
// b=3으로 변경
PUT/ member001
content-type: text
{"a" : 1, "b" : 3}
// 데이터 없을때
PUT/ member/001 http1.1 PUT/ member/001
content-type: text ->
{ "a" : 1, "b" : 3}
// 데이터 생성
PUT/ member001
content-type: text
{"a" : 1, "b" : 3}
④ PATCH
- 요청을 보낼 때 수정하는 일부분만 교체한다.
- PATCH 요청
// 데이터 있을 때 정보 변경
PUT/ member/001 http1.1 PUT/ member/001
content-type: text -> { "a" : 1, "b" : 2 }
{"b" : 3}
// b=3으로 변경
PUT/ member001
content-type: text
{"a" : 1, "b" : 3}
'CS전공지식 노트 > 3. 네트워크' 카테고리의 다른 글
네트워크 #9 : 대규모 트래픽으로 인한 서버 과부하 해결방법 (0) | 2023.08.21 |
---|---|
네트워크 #8 : 네트워크 장치 (0) | 2023.08.21 |
네트워크 #6 : 로컬스토리지,세션스토리지, 쿠키 (0) | 2023.08.16 |
네트워크 #5 : HTTP (0) | 2023.08.16 |
네트워크 #4 : IP주소체계 (0) | 2023.08.13 |