[TIL] 230425 사용자 인증 방식 종류와 특징 | Cookies / JWT / OAuth

---

TIL 학습목표

• 사용자 인증방식의 종류와 특징을 안다.
• Cookies / JWT / OAuth 의 장단점을 안다.

---

1) 사용자 인증이란?

로그인이 필요한 서비스의 경우, 해당 사용자가 회원인가? 회원이라면 어느 회원인가? 등
사용자를 인증하는 과정이 필요하다.
즉, ID입력 PW 입력 등 일련의 로그인 과정 전체를 아울러 사용자 인증 이라고 한다.

그런데, 매번 로그인 과정 마다
사용자는 ID와 PW를 제공하고,
서버는 새롭게 DB와 대조하여 사용자를 인증한다면,

사용자는 불편함을, 서버는 리소스 낭비와 응답속도저하 라는 단점이 생긴다.

이를 보완하기 위해 부분적으로 "client와 server의 연속된 동작 상태정보를 저장하는 형태", 즉 stateful 한 형태를 만들어야했고, 인증관련 정보를 저장할 저장소의 필요성이 생겼다.

이를 충족키위해 리소스와 보안을 고려한 여러 사용자 인증 방식이 생겨났고,
그 중 서버기반인증 과 토큰기반인증 을 살펴보자.

 

종류	특징	장단점	해당하는 방식
서버 기반 인증	서버에 저장소(Session)를 가진다	+서버에서 관리하여 보안에 유리 / -서버부하↑	Cookie-Session 등
토큰 기반 인증	클라이언트에 저장소(Token)를 가진다	-토큰에 정보가 있어 보안에 불리 / +서버부하↓	OAuth , JWT 등

 

[좌]서버 기반 인증(Cookie-Session) / [우]토큰 기반 인증(OAuth, JWT)

---

2) 사용자 인증 방식의 종류, 장단점 Cookies / JWT / OAuth

▶Cookies-sessions 서버기반인증

전통적인 방식이다. HTTP의 stateless한 속성을 보완할 필요성이 생겨서 탄생했다.

+장점- 처음의 목적이던 부분적 stateful 유지 가능
+장점- 매번 보내줘야만하는 정보가 있을 때 유리
-단점- 완전히 stateless 하지 않다 | session에서 저장을 하므로 서버측 부하↑
-단점- 한 계정이 여러 클라이언트에서 접속을 요구할 때 어떻게 session을 처리할 것인가? 하는 한계점
         ex) PC+mobile 동시접속

---

▶JWT (JSON Web Token) 토큰기반인증

토큰 자체가 Data를 가지고 있고, Header / Payload / Verify Signature로 구성되어있다.

https://jwt.io/

헤더 (Header)

{
  "typ": "JWT",	  // 토큰의 타입
  "alg": "HS256"  // 해싱 알고리즘을 지정 | 보통 HMAC SHA256 혹은 RSA | signature 부분에서 사용
}

정보 (Payload)

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

서명 (Signature) | Header의 인코딩 값과, Payload의 인코딩 값을 합친 후 주어진 비밀키로 해쉬를 하여 생성한다.

HMACSHA256( 		//Header에서 정의한 alg
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  <your-256-bit-secret> //secret key 입력공간
)

+장점- local stoarge 사용 = 클라이언트에서 인증정보저장 | 더 stateless해져서 서버측 부하↓
+장점- local storage(토큰)에 인증관련 정보가 들어있으므로, 단일 계정이 여러 클라이언트에 동시접속가능
-단점- Packet(보내는 데이터) 양이 크다.
-단점- 토큰 자체를 탈취하면 ID, PW 자체를 알 수 있다. 보안↓
         (따라서 HTTPS 통신을 권장한다. = 보안↑)

▶OAuth 토큰기반인증

구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제3자 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임(Delegated Authorization)받을 수 있는 표준 프로토콜

즉, 클라이언트가 타사 플랫폼으로부터 유저 정보 접근 권한을 위임 받아, 인증에 사용하는 인증 방식

기존 JWT 에서 사용하는 Refresh Token - Access Token 구조

OAuth 2.0 동작 방식

기존의 Access Token-Refresh Token을 이용한 인증 방식은 한 서버에서 모두 관리하는 반면,
OAuth에서는 Authorization Server에서 인증+권한 관리를 하고 Resource Server에서는 자원에 대한 관리만 한다.

장점: Access Token을 지속적으로 발급 | 보안↑ = Token방식의 단점보완
단점: 필요한 Resource가 너무 많다. Access Token이 만료될 때마다 새롭게 발급하는 과정에서 생기는 HTTP 요청이 잦다.

*Access Token: API를 요청할 때 사용하는 토큰. 유효기간이 짧다.
*Refresh Token: Access Token의 유효기간이 만료되면 Access Token을 다시 발급받기 위해 사용되는 Token. Access Token보다 유효기간이 길다.

참고1

참고2

---

3) 알게 된 점  (Learnd)

각 인증 방법의 특징과 장단점을 알게 되었다.
각각의 방법을 잘 이해하고 보안과 쓰임새를 고려해, 훗날 선택하여 활용 할 수 있도록 하자.

+추후 더 상세히 다루도록 하자