로그인 기능 구현 시 고려 사항(쿠키, 세션, 로컬 스토리지, 인증과 인가, 토큰, Oauth)

로그인 기능을 위한 사전 지식

 

쿠키란?

쿠키는 클라이언트(브라우저) 로컬에 저장되는 키와 값이 들어가 있는 작은 데이터 파일입니다.

 

F12로 개발자 모드를 켜고 document.cookie를 하면 현재 쿠키 정보가 나옵니다.

 

사용자 인증이 유효한 시간을 명시할 수 있으며, 유효시간이 정해지면 브라우저가 종료되어도 인증이 유지됩니다.

쿠키의 만료시간

쿠키는 클라이언트의 상태 정보를 로컬에 저장했다가 참조합니다.

 

클라이언트에 300개까지 쿠기가 저장 가능하며, 하나의 도메인당 20개의 값을 가질 수 있습니다.

 

하나의 쿠키값은 4KB까지 저장됩니다.

 

쿠키의 구성 요소

• 이름 : 각각의 쿠키를 구별하는 데 사용되는 이름
• 값 : 쿠키의 이름과 관련된 값
• 유효시간 : 쿠키의 유지시간
• 도메인 : 쿠키를 전송할 도메인, 만약 이 값이 현재 탐색 중인 도메인과 일치하지 않는다면 "타사 쿠키"로 간주되어 브라우저에서 거부합니다.
• 경로 : 쿠키를 전송할 요청 경로
• httpOnly : 해커들이 자바스크립트로 쿠키를 가로채려고 시도할 수 있습니다.  이러한 경우를 막기 위해 HttpOnly 속성을 true로 설정하면 CSS, XSS와 같은 공격이 차단됩니다.
• Secure : Javscript가 아닌 네트워크를 직접 감청하여 쿠키를 가로챌 수도 있습니다. 따라서 HTTPS 프로토콜을 사용하여 데이터를 암호화하면 쿠키 또한 암호화됩니다. secure 접미사를 사용하면 브라우저는 HTTPS가 아닌 통신에서는 쿠키를 전송하지 않습니다.
• SameSite : 해당 설정에 따라 도메인 당 쿠키 설정이 제한됩니다.

크로스 사이트 스크립팅 (CSS, XSS) 공격을 통한 Cookie 탈취

크로스 사이트 스크립팅 공격의 예시

https://unabated.tistory.com/entry/7-XSSCSS

7. XSS(CSS)

 

크로스 사이트 스크립팅은  SQL injection과 함께 웹 상에서 가장 기초적인 취약점 공격 방법의 일종으로, 악의적인 사용자가 공격하려면 사이트에 스크립트를 넣는 기법입니다.

 

보통 의도치 않은 행동을 수행시키거나 쿠키나 세션 토큰 등의 민감한 정보를 탈취합니다.

 

 

기본적으로 cookie는 JavaScript를 통해 조회가 가능합니다.

document.cookie = '';

 

 

이를 대응하기 위해 HttpOnly 옵션을 부여하여 HTTP 통신 외에는 Cookie에 접근이 불가능하도록 할 수 있습니다.

 

 

사이트 간 요청 위조(CSRF, XSRF) 공격을 통한 쿠키 탈취

사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말합니다.

 

쿠키에 별도로 설정을 가하지 않는다면, 크롬을 제외한 브라우저들은 모든 HTTP 요청에 대해서 쿠키를 전송하게 됩니다.

 

CSRF(Cross Site Request Forgery)는 이 문제를 노린 공격입니다.

• 1. 공격 대상 사이트는 쿠키로 사용자 인증을 수행함.
• 2. 피해자는 공격 대상 사이트에 이미 로그인되어있어서 브라우저에 쿠키가 있는 상태
• 3. 공격자는 피해자에게 그럴듯한 사이트 링크를 전송하고 누르게 함. ( 공격 대상 사이트와 다른 도메인)
• 4. 링크를 누르면 HTML 문서가 열리는데, 이 문서는 공격 대상 사이트에 HTTP 요청을 보냄.
• 5. 이 요청에는 쿠키가 포함되어 있으므로 공격자가 유도한 동작을 실행할 수 있음.

 

SameSite 속성을 통해 Strict를 적용하면 해당 쿠키는 크로스 사이트 요청에는 전송되지 않습니다.

 

만약 SameSite 속성이 None이라면 반드시 해당 큐키는 Secure 쿠키여야 합니다.

 

Secure 쿠키는 HTTPS(암호화된)가 적용된 요청에만 전송되는 쿠키입니다.

 

구글의 HttpOnly, Secure, SameSite 옵션들

쿠키의 동작 방식

• 1. 클라이언트가 페이지를 요청
• 2. 서버에서 쿠키를 생성
• 3. HTTP 헤더에 쿠키를 포함시켜 응답
• 4. 브라우저가 종료되어도 쿠키 만료 기간이 있다면 클라이언트에서 보관하고 있음
• 5. 같은 요청을 할 경우 HTTP 헤더에 쿠키를 함께 보냄
• 6. 서버에서 쿠키를 읽어 이전 상태 정보를 변경할 필요가 있을 때 쿠키를 업데이트하여 변경된 쿠키를 HTTP 헤더에 포함시켜 응답

(쿠키의 동작 방식)https://interconnection.tistory.com/74

---

세션이란?

쿠키처럼 키와 값을 가진 작은 데이터인데 서버에 저장하고 참조합니다.

 

세션은 서버에 저장되며 고유한 SessionID를 생성 후에 클라이언트에 SessionID가 담긴 쿠키를 전송합니다.

 

이후 클라이언트는 SessionID 쿠키를 요청 시마다 전송하여 서버는 이를 통해 어떤 클라이언트의 요청인지 구분할 수 있습니다.

 

쿠키와 어떤 점이 다를까요?

• 쿠키는 클라이언트, 세션은 서버에 데이터를 저장합니다.
• 쿠키와 달리 저장 용량에 대해 제한이 없습니다.(쿠키는 하나당 4KB)
• 세션은 브라우저가 종료될 때까지 계속 유지합니다. (쿠키는 만료 시간을 가지고 있음 + 브라우저가 종료되어도 만료시간까지 유지)
• 데이터를 서버에서 저장하고 참조하기 때문에 사용자가 많아지면 서버에 과부하를 주게 됩니다.
• 브라우저가 서버에 요청을 하게 되면 서버는 클라이언트를 구분하기 위해 세션 ID라는 유일한 ID를 부여합니다.

세션의 동작 과정

https://chrisjune-13837.medium.com/web-%EC%BF%A0%ED%82%A4-%EC%84%B8%EC%85%98%EC%9D%B4%EB%9E%80-aa6bcb327582

1. 클라이언트가 서버에 로그인 요청을 합니다.

 

2. 서버는 클라이언트의 로그인 유효성을 검사하고 unique 한 sessionid를  응답 헤더에 set-cookie : sessionid:a 1x2 fjx를 추가하여 응답합니다.

 

3.  클라이언트는 이후 서버에 요청할 때 전달받은 sessionid : a1x2fjz 쿠키를 자동으로 요청 헤더에 추가하여 요청합니다.

 

4. 서버에서는 요청 헤더의 sessionid 값을 저장된 세션 저장소에서 찾아보고 유효한지 확인 후 요청을 처리하고 응답합니다.

 

 

쿠키/세션을 사용하는 이유는 뭘까요?

HTTP 프로토콜의 특성이자 약점을 보완하기 위해서 쿠키 또는 세션을 사용합니다.

 

기본적으로 HTTP 프로토콜 환경은 "connectionless, stateless" 특성을 가지기 때문에 서버는 클라이언트가 누구인지 매번 확인해야 합니다.

 

만약 사용자가 권한이 있는 기능을 사용한다면 서버는 클라이언트가 누구인지 계속 확인해야 합니다.

어떤 일을 할 때마다 계속 사용자가 로그인해야 한다면 얼마나 불편할까요

 

쿠키/세션을 사용하게 된다면 쿠키/세션이 상태 정보를 가지고 있기 때문에 이러한 정보를 가지고 사용자에게 편리함을 제공할 수 있습니다.

 

connectionless란?

클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징

(HTTP 1.1에서 Connection 헤더에 keep-alive라고 설정하면 연결을 유지할 수 있음)

 

stateless란?

통신이 끝나면 상태를 유지하지 않는 특징

 

쿠키 사용의 예시

"아이디와 비밀번호를 저장하시겠습니까?"

쇼핑몰의 장바구니 기능

자동 로그인, "오늘 더 이상 이 창을 보지 않음"

쇼핑 사이트는 쿠키를 사용하여 사용자가 이전에 본 항목을 추적하여 사이트에서 사용자가 좋아할 만한 다른 상품을 맞춤형 추천 및 광고

 

 

웹 스토리지

웹 스토리지는 쿠키와 비슷하게 해당 도메인과 관련된 특정 데이터를 서버가 아니라 클라이언트에 저장할 수 있도록 하는 HTML5부터 새롭게 지원하는 기능입니다.

 

로컬 스토리지

• 브라우저를 종료해도 유지되는 데이터로, 명시적으로 지우지 않는 한 영구적으로 저장됩니다.
• 도메인별로 생성되며, 다른 도메인의 로컬 스토리지에는 접근이 불가능합니다.
• 서로 다른 브라우저 탭이라도 동일한 도메인이면 동일한 로컬 스토리지를 사용합니다.
• 지속적으로 필요한 정보를 저장하기 좋습니다.(자동 로그인)

세션 스토리지

• 같은 도메인이라도 탭/윈도 단위로 세션 스토리지가 생성됩니다.
• window 객체와 동일한 유효 범위 및 생존 기간을 가지며, 탭/윈도가 닫히면 데이터가 삭제됩니다.
• 잠시 동안 필요한 정보를 저장하기 좋습니다.(일회성 로그인)

 

 

쿠키 vs 세션 vs 세션 스토리지  vs 로컬 스토리지 vs 캐시

• 쿠키는 클라이언트에 저장되고 상태 정보가 저장되어 있음.
• 세션은 서버에 상태 정보가 저장되고 클라이언트는 쿠키에 세션 아이디를 가지고 있음.
• 세션 스토리지는 클라이언트에 저장되고 윈도가 닫히면 데이터가 삭제됨.
• 로컬 스토리지는 클라이언트에 저장되고 지우지 않는 한 영구적으로 저장됨.
• 캐시는 클라이언트에 저장되지만 오직 웹페이지 로딩 속도 개선을 위해서만 사용됨. (위의 4개는 사용자에게 편의를 제공하기 위해 사용)

 

 

로그인이란?

컴퓨터 보안에서 접근 허가 증명을 얻기 위해 사용자 인증으로 개인이 컴퓨터 시스템에 접근하는 작업을 말합니다.

사용자 자격 증명은 일반적으로 사용자 이름과 그에 일치하는 비밀번호 형태를 이루며 이를 기반으로 사용자는 접근을 얻기 위해 시스템에 로그인할 수 있으며 더 이상 필요하지 않을 때 로그아웃 할 수 있습니다.

 

로그인 과정으로는 클라이언트는 요청 헤더에 인코딩 된 아이디와 비밀번호를 서버에게 보내고 서버는 DB에서 회원정보의 유효성을 검사하여 결과를 반환해줍니다.

인증과 인가란?

인증과 인가는 자원을 적절한/유효한 사용자들에게 전달/공개하기 위한 방법입니다.

 

간단히 말해 인증은 회사의 출입문에 사원증을 찍고 들어가는 행위라고 할 수 있습니다.

회사에 출입문을 찍고 들어갔기 때문에 회사 내의 화장실도 가고 회의실 등 시설물들을 이용할 수 있습니다.

 

하지만 중요한 데이터베이스 서버실에 들어가고 싶을 때는 권한에 따라 제한될 수 있습니다.

이를 인가라고 합니다.

 

웹에서는 로그인하는 과정이 인증이며 다른 사람들의 글을 읽을 수 있습니다.

하지만 다른 사람의 글을 수정할 순 없습니다.(인가가 적용되었습니다)

 

그런데 만약 사용자가 어떤 일을 할 때마다 로그인을 해야한다면 정말 불편하겠죠?

 

1. 클라이언트가 관리하는 브라우저 스토리지를 사용하자

따라서 브라우저의 스토리지의 힘을 빌립니다.

로컬 스토리지, 세션 스토리지, 쿠키 등의 힘을 빌립니다.

사용자가 인증이 필요한 요청을 할때 브라우저에 있는 아이디/비밀번호를 같이 넣어서 요청하게 됩니다.

그러면 사용자 입장에서는 편리하게 자원에 접근할 수 있습니다.

 

2. 서버가 관리하는 세션을 사용하자

하지만 스토리지에 사용자의 정보가 존재하기 때문에 보안에 취약합니다.

이러한 문제점을 해결하기 위해서 서버의 힘을 빌리기 위해 세션을 사용합니다.

사용자가 처음에 로그인을 하게 되면 서버는 응답 헤더에 사용자에게 세션 ID를 부여합니다.

사용자의 아이디/비밀번호보다는 세션 ID가 스토리지에 저장되기 때문에 안전하게 사용할 수 있습니다.

또한 만료기간을 설정할 수 있어 만료기간이 지나면 해당 세션 ID는 의미가 없어집니다.

또한 세션을 서버에서 관리하기 때문에 탈취가 된 세션 ID를 서버에서 삭제한다면 해당 세션ID를 사용할 수 없게 됩니다.

 

하지만 세션에도 단점이 존재합니다.

만약 서버가 여러 대가 존재하게 된다면 어떻게 될까요?

A, B, C 서버가 존재할 때 만약 A서버에서 세션 아이디를 할당받고 A서버에서 세션아이디를 관리하고 있습니다.

 

그런데 이후에 접근할 때 B서버에 가서 세션아이디를 보여주면 어떻게 될까요?

B서버는 해당하는 세션 아이디에 대한 정보가 없기 때문에 다시 로그인을 하라고 요청합니다.

 

각 서버에서 세션을 관리하기 때문에 생기는 문제이기 때문에 공용 세션 스토리지라는 서버의 모든 세션을 관리하는 스토리지를 사용하면 해결할 수 있습니다.

 

하지만 클라이언트가 많아지게 되면 많은 정보를 관리해야 하는 세션 스토리지가 터질 수 도 있습니다.

 

 

 

현재까지의 구조는 다음과 같습니다

클라이언트 -> 로드밸런서 -> 서버 여러 대 ->  공용 세션 스토리지(Redis DB)

 

3. JWT(JSON WEB TOKEN)을 사용하자.

JWT란 Json 포맷을 이용하여 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token입니다.

 

일반 토큰과 클레임 토큰의 차이점

일반 토큰은 주로 의미 없는 문자열로 구성되어 있습니다.

클레임 토큰은 토큰 안에 사용자 정보나 데이터 속성을 저장하고 있습니다.

 

토큰 자체를 정보로 활용하는 방식이며 주로 회원 인증이나 정보 전달에 사용되는 JWT는 아래의 로직에 따라 처리됩니다.

https://mangkyu.tistory.com/56

static 변수에 저장하는 이유는 HTTP 통신을 할 때마다 JWT를 HTTP 헤더에 담아 보내는데, 이를 로컬 스토리지에 계속 불러오면 오버헤드가 발생하기 때문입니다.

 

클라이언트에서 JWT를 포함해 요청을 보내면 서버는 허가된 JWT인지를 검사합니다.

만약 사용자가 로그아웃을 할 경우 로컬 스토리지에 저장된 JWT 토큰을 삭제합니다.

실제 서비스의 경우 로그아웃 시, 사용했던 토큰을 blacklist라는 DB 테이블에 넣어 해당 토큰의 접근을 막는다고 합니다.

 

JWT의 구조

JWT는 Header, Paylaod, Signature의 3 부분으로 이루어지며, Json 형태의 각 부분은 Base64로 인코딩 되어 표현됩니다.

Base64는 암호화된 문자열이 아니고 같은 문자열에 대해 항상 같은 인코딩 문자열을 반환합니다.

또한 각각의 부분을 이어 주기 위해 . 구분자를 사용합니다.

예를 들면 xxxxx.yyyyy.zzzzz 는 헤더.페이로드.서명 으로 이해할 수 있습니다.

 

• Header(헤더)

토큰의 헤더는 type과 alg 두 가지 정보로 구성됩니다.

typ : 토큰의 타입을 지정 ex) JWT

alg : 알고리즘 방식을 지정하며, 서명(Signature) 및 토큰 검증에 사용 ex) HS256(SHA256) 또는 RSA

 

• PayLoad(페이로드)

토큰의 페이로드에는 토큰에서 사용한 정보의 조각들인 클레임이 담겨 있습니다.

클레임은 총 3가지로 나누어지며 Json형태로 다수의 정보를 넣을 수 있습니다

 

1. 등록된 클레임

iss : 토큰 발급자
sub : 토큰 제목
exp : 토큰의 만료시간
nbf : 토큰의 활성 날짜 ( 이 날이 지나기 전의 토큰은 활성화되지 않음)
iat : 토큰 발급 시간 (토큰 발급 이후의 경과 시간을 알 수 있음)
jti : JWT 토큰 식별자(중복 방지를 위해 사용하며 일회용 토큰 등에 사용)

2. 공개 클레임

사용자 정의 클레임으로, 공개용 정보를 위해 사용됩니다.
충돌 방지를 위해 URI 포맷을 이용하며 URI로 정의해야 합니다.

3. 비공개 클레임

사용자 정의 클레임으로, 서버와 클라이언트 사이에 임의로 지정한 정보를 저장합니다.

 

페이로드의 예시

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

 

• Signature(서명)

 

서명 부분을 생성하려면 인코딩 된 헤더, 인코딩된 페이로드의 값을 각각 BASE64로 인코딩하고, 인코딩한 값을 비밀 키를 이용해 헤더에서 정의한 알고리즘으로 해싱한 후, 다시 BASE64로 인코딩하여 생성합니다.

 

예를 들어 HMAC SHA256 알고리즘을 사용하려는 경우 서명은 다음과 같은 방식으로 생성됩니다.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

 

서명은 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드입니다.

 

서명은 메시지가 도중에 변경되지 않았는지 확인하는 데 사용되며 개인 키로 서명된 토큰의 경우 JWT의 보낸 사람이 누구인지 확인할 수도 있습니다.

 

JWT를 사용하고 이러한 개념을 실제로 적용하려면 jwt.io 디버거를 사용하여 JWT를 디코딩, 확인 및 생성할 수 있습니다.

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1

 

Refresh Token이란?

리프레시 토큰은 JWT 로그인 방식의 보안상의 단점을 보완하기 위해 구현됩니다.

사용자가 로그인하여 리소스에 접근할 수 있는 토큰을 액세스 토큰이라고 합니다.

하지만 액세스 토큰이 탈취된다면 해커는 로그인 한 유저처럼 리소스에 접근할 수 있습니다.

하지만 토큰은 서버에서 제어할 수 없기 때문에 발급한 토큰의 유효기간을 짧게 하여 보안성을 높입니다.

 

하지만 유효기간을 짧게 잡으면 사용자 입장에서 로그인을 자주해야 하기 때문에 편의성은 떨어지게 됩니다.

따라서 refresh token이 등장하게 됩니다.

 

refresh token은 access token과 함께 발급되어 access token의 유효기간이 만료되었을 때 access token을 재발급받을 수 있는 열쇠 역할을 하게 됩니다.

 

Sliding Session이란?

글을 작성하는 도중 토큰이 만료된다면 From Submit 요청을 보낼 때 작업이 정상적으로 처리되지 않고, 이전에 작성한 글이 날아가는 등의 불편함이 존재합니다.

따라서 서비스를 지속적으로 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법입니다.

 

JWT 단점 및 고려사항

• 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다.
• 정보가 많아질수록 토큰 길이가 늘어나 네트워크에 부하를 줄 수 있다.
• 페이로드 자체는 암호화된 것이 아니라 BASE64로 인코딩 된 것이다.
• 따라서 중간에 페이로드를 탈취하여 디코딩하면 데이터를 볼 수 있으므로 중요한 데이터를 넣지 말아야 합니다.
• JWT가 상태를 저장하는 것이 장점이자 단점으로 다가올 수 있습니다. 세션과 다르게 서버에서 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 합니다.

 

4. Oauth를 사용하자

Oauth란?

간단히 말해 나의 서비스에서 사용자에게 제3자의 서비스를 할 수 있게 하는 개방형 표준 프로토콜입니다.

예를 들어 외부 웹 어플리케이션에 Google로 로그인하면 API를 통해 연동된 계정의 Google Calendar 정보를 가져와 사용자에게 보여줄 수 있습니다.

 

다음과 같이 외부 소셜 계정을 기반으로 간편하게 회원가입 및 로그인할 수 있는 웹 어플리케이션을 쉽게 찾아볼 수 있습니다.

https://showerbugs.github.io/2017-11-16/OAuth-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

이 때 사용되는 프로토콜이 Oauth입니다.

Oauth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. (위키백과)

 

Oauth의 등장배경

Oauth가 없을때는 A사이트에서 B사이트의 리소스를 가져오기 위해서는 다른 사이트의 ID와 Password를 직접 입력 받아 저장하여 필요할 때마다 사용했습니다.

 

이는 매우 간단하지만 문제점들이 발생합니다.

• 사용자 : A사이트에 B사이트의 ID와 Password를 넘겨주는 것에 대해 신뢰할 수 없다.
• A사이트 : 사용자들의 ID와 Password를 받았기 때문에 보안 문제가 생기는 경우 모든 책임을 져야한다.
• B사이트 : A사이트를 신뢰할 수 없다.

위와 같은 문제를 해결하기 위해 2006년 트위터 개발자와 Gnolia의 개발자가 안전한 인증방식에 대한 논의를 하며 Oauth가 등장했고 2010년에 Oauth 1.0이 발표되었습니다.

 

현재는 Oauth의 세션 고정 공격을 보완한 Oauth 1.0a를 거쳐, Oauth의 구조적인 문제점을 해결하고, 핵심요소만을 차용한 유사 프로토콜 WRAP을 기반으로 발표한 Oauth 2.0이 많이 사용되고 있습니다.

 

Oauth2.0 용어

• Resource Server : Oauth2.0 서비스를 제공하고 자원을 관리하는 서버(Google, Naver, Kakao)
• Resource Owner : Resource Server의 계정을 소유하고 있는 사용자(사용자)
• Client : Resource Server의 API를 사용하여 데이터를 가져오려고 하는 사이트(개발 사이트)
• Authorization Server : Client가 Resource Server의 서비스를 사용할 수 있게 인증하고 토큰을 발행하는 서버(인증 서버)
• Access Token : 자원 서버에 자원을 요청할 수 있는 토큰
• Refresh Token : 인증 서버에 Access Token을 요청할 수 있는 토큰

Oauth 인증방식

https://datatracker.ietf.org/doc/html/rfc6749#section-1.2

1. 클라이언트가 사용자에게 허가를 요청하고 사용자는 승인합니다.

2. 클라이언트가 인증서버에게 Access Token의 발급받습니다.

3. Access Token을 통해 자원을 요청합니다.

 

 

SSL/ TLS1.3이란?

HTTP 통신을 통해 클라이언트가 서버에게 요청을 보낼때는 다이렉트로 가는것이 아니라 중간에 인터넷 네트워크를 거쳐서 지나가게 됩니다.

따라서 많은 네트워크들을 거쳐가는 도중에 민감한 패킷의 정보를 악의적인 사람이 보게 되거나 수정하면 문제가 발생할 수 있습니다.

 

따라서 TLS (Transport Layer Security) 전송 계층 보안이 등장하게 됩니다.

사실 TLS가 있기전에 SSL이라는 기술이 존재했습니다.

이 SSL 3.0버전이 발전하여 TSL 1.0버전이 나오게 되었고 2018년에 TLS 1.3버전이 나오게 되었습니다.

따라서 SSL/TSL 이라는 용어들이 많이 보이지만 사실상 TSL은 SSL의 업그레이드 버전입니다.

 

패킷을 보내기 전에 전송계층에서 패킷을 암호화하고 패킷을 받는 쪽은 전송계층에서 다시 패킷을 복호화하여 사용하는 구조입니다.

 

Session vs JWT vs Oauth

그래서 어떤걸 사용해야 할까요?

 

공부하면서 느낀것이지만 정답은 존재하지 않는것 같습니다.

 

나의 서비스에 적합한것을 고르는것이 최선입니다.

 

 

AccessToken, Refresh Token(DB에 저장)을 사용한 무상태 JWT를 사용한다면 서버를 많이 확장하더라도 크게 문제가 없는 장점이 있습니다.

 

하지만 넷플릭스의 다중 로그인 계수 제한, 특정 사용자 강제 로그아웃 등 유저를 관리하는데는 단점이 존재합니다.

무상태성을 가진 강제로 토큰을 종료할 수 없기 때문입니다.

 

이를 방지하고자 토큰에 상태를 넣는다면 이는 세션과 다를게 없기 때문에 토큰의 장점을 잃어버립니다.

 

또한 보안성을 강화하기 위한 방법으로는 아무리 HTTPS로 토큰을 보내도 중간자 공격 등으로 토큰을 훔친 해커는 이를 사용할 수 있습니다.

 

따라서 AccessToken이 유효하더라도 사용자의 IP주소가 바뀌면 다시 로그인을 하도록 하는 방식을 사용할 수 있습니다.

 

 

 

출처

https://mycloudtutorials.com/2021/06/session-vs-jwt-token-for-authorization/(Sesstion vs JWT Token)

https://www.youtube.com/watch?v=y0xMXlOAfss (10분 테코 톡 : 토니의 인증과 인가)

https://interconnection.tistory.com/74(쿠키와 세션 개념)

https://hahahoho5915.tistory.com/32(쿠키,세션 특징 및 차이)

https://www.kaspersky.com/resource-center/definitions/cookies(What are Cookies?)

https://unabated.tistory.com/entry/7-XSSCSS(XSS)

https://m.blog.naver.com/sehyunfa/221767776133(인증 토큰을 활용한 SSO)

https://ko.wikipedia.org/wiki/%EB%A1%9C%EA%B7%B8%EC%9D%B8(로그인 - 위키백과)

https://mangkyu.tistory.com/56(JWT란?)

https://jwt.io/(JWT공식문서)

 

https://tecoble.techcourse.co.kr/post/2021-07-10-understanding-oauth/(Oauth 개념 및 동작 방식)

https://datatracker.ietf.org/doc/html/rfc6749(RFC 6479 - The Oauth 2.0 문서)

https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/

https://www.youtube.com/watch?v=EPcQqkqqouk&t=389s(에단의 TLS)