[사용자 인증방식] 세션,JWT,OAuth

0. 세션(서버 기반 인증 시스템)

1) 유저가 로그인을 하면 

2) 서버는 아이디와 비밀번호를 회원 DB 에서 확인해본다. 

3) 회원정보가 맞다면 세션 저장소(ex: 메모리, 데이터베이스 등)에서 회원 정보 세션을 생성한다.

4) 세션 저장소에서 서버로 Session ID를 발급한다. 

5) Session ID는 사용자의 웹브라우저에 전달된다. 

6) 사용자가 권한이 필요한 페이지에 접속 요청을 하면, 사용자의 브라우저는 요청 헤더에 쿠키(session_id가 포함)를 포함 시켜 서버에 전달한다.

7,8) 서버는 받은 요청 헤더의 쿠키 정보에서 'session id' 값을 추출해서 세션 ID를 사용해서 자신의 세션 저장소에서 해당 세션 ID와 연결된 사용자 정보를 찾는다. 

9) 세션 ID에 해당하는 사용자 정보가 있다면 페이지는 정상적으로 제공된다. 

 

🔸세션아이디를 발급받으면 프론트엔드에서는 쿠키에 저장해야하는건가 아니면 session id를 발급받으면 자동으로 쿠키에 key-value 형태로 저장되는건가? (서버쪽을 모르니 챗지피티한테 물어봤다)

세션 ID를 발급받으면, 웹 서버가 Set-Cookie라는 HTTP 헤더를 사용해 웹 브라우저에게 세션 ID를 포함하는 쿠키를 저장하라고 지시합니다. 웹 브라우저는 이 지시를 따라 자동으로 쿠키에 세션 ID를 key-value 형태로 저장합니다.

프론트엔드 코드가 아닌, 서버의 응답 헤더에서 Set-Cookie 지시가 오면 웹 브라우저는 이를 알아서 처리하여 쿠키를 저장합니다. 따라서, 프론트엔드에서는 별도의 작업 없이 웹 브라우저가 쿠키를 저장하게 됩니다.

예를 들어, 서버에서 응답 헤더에 다음과 같은 내용이 포함되면:

 

Set-Cookie: sessionId=abc123; Path=/; HttpOnly

웹 브라우저는 sessionId라는 key에 abc123이라는 value를 가진 쿠키를 자동으로 저장합니다. 이후 웹 브라우저가 서버에 요청을 할 때마다 해당 쿠키를 자동으로 포함하여 전송합니다.

 

🔸특징

- 매번 GET/POST 를 요청할 때마다 DB를 조회해보기 때문에 하나하나의 요청마자 엄격하게 유저를 체크해볼수 있다.

- 단점은 세션은 메모리 또는 DB 에 저장하는데, 로그인 중인 사용자가 늘어날 경우에는 DB에 부하가 걸리게 된다. 

 

1. JWT(토큰 기반 인증시스템)

1) 유저가 폼에 아이디와 비밀번호를 입력하여 서버에 전송한다.

2) 서버는 회원 DB에서 아이디와 비밀번호를 확인한 후 맞다면 JWT 를 생성한다. 

3) JWT 는 응답으로 사용자의 웹브라우저에 전달된다. 

4) 사용자가 권한이 필요한 페이지에 접속 요청을 하면, 웹브라우저는 HTTP 헤더(Authorization 헤더) 에 JWT를 포함시켜 서버에 전달한다. 

5,6) 서버는 받은 JWT를 검증해보고 맞다면

7) 요청된 페이지나 정보를 응답한다.

 

🔸특징

- 매번 GET/POST 요청을 할 때마다 DB를 조회할 필요가 없어 DB 부담이 적다. 

- 그래서 유저가 많은 사이트들이 즐겨쓴다. 

- 단점은 유저의 JWT를 훔쳐가면 그 사람의 로그인을 막거나 할수있는 방법이 없다. 

2. OAuth(Client 의 인증과 인가의 분리)

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

 

🔸OAuth 사용 이전 (인증과 인가를 우아한 캘린더가 둘다 하고 있음)

- 우아한 캘린더를 만든다고 해보자. 우아한 캘린던든 구글 캘린더의 일정을 추가하거나 일정을 볼수있어야함.

- 유저의 구글 ID와 PW를 받고, 구글 로그인 한 뒤에 사용자 캘린더에 대한 정보를 받고 이를 가공해서 유저에게 서비스를 제공해야했다. 

- 유저 입장에서는 구글 ID,PW를 줘야하는데 우아한 캘린더를 믿을 수 있을까? 더불어 구글이 아무리 보안을 잘한다 하지만, 우아한 캘린더쪽에서 잘못하다가 보안이 털려버리면 서비스를 접어야함

- 이 문제는 우아한 캘린더가 구글의 아이디와 비밀번호를 직접적으로 관리해서 생긴 문제이다. 

 

🔸OAuth (인증은 유저가 수행하고,권한은 우아한 캘린더가 받는 것)

 

1) 유저는 구글에 직접 ID와 PW를 입력해서 인증과정을 수행한다.

2) 우아한 캘린더는 인증과정 어디에도 포함되지 않아서 탈취당할 염려가 없다. 인증이 유효하다고 확인이 되면, 구글은 캘린더에 접근할 수 있는 권한을 줌

3) 우아한 캘린더는 부여받은 권한으로 구글 캘린더에 접근할 수 있다. 

 

🔸OAuth 주요 용어

 

 

🔸OAuth 작동방식

1) 유저가 브라우저에서 소셜로그인 버튼을 클릭한다. 

아래의 User-Agent 는 브라우저이다.

2) 우리의 서비스(우아한 캘린더) 는 로그인 페이지 URL 을 제공하면 브라우저는 구글 서버의 로그인 페이지에 접근한다.

그리고 구글의 로그인 페이지를 반환한다.

 

response_type	authorization 코드를 나타냄
client_id	식별자를 뜻함 (구글이나 깃허브 페이지에서 클라이언트 등록할 때 봤던 client id)
redirect_uri	-  OAuth 2.0 인증 프로세스 중에 클라이언트 애플리케이션으로 사용자를 다시 리디렉션(페이지 전환)시킬 때 사용되는 URL을 지정하는 데 사용 - 사용자가 제3자 애플리케이션(예: 웹사이트나 모바일 앱)에서 OAuth 제공자(예: Facebook, Google)를 통해 로그인하려 할 때, 사용자는 먼저 OAuth 제공자의 로그인 페이지로 이동함. 사용자가 그곳에서 로그인하고 해당 애플리케이션에 대한 액세스를 승인한 후, redirect_uri에 지정된 URL로 다시 리디렉션되며, 이 때 액세스 토큰이나 인증 코드가 함께 전달됨
scope	- Resource Server에서 사전에 사용 가능하도록 미리 정의한 기능 - 글 작성하기, ID알기, Email 알기, 캘린더 일정 입력하기 등등 - 페이스북이든 구글이든 로그인 되었다면, 그 서비스 안에서 사용할 수 있는 모든 기능

 

 

3) 로그인 과정에서 유저가 인증을 함

Client 는 로그인 페이지 URL 만 제공하고, 인증 과정 수행은 Resource Owner 는 Authorization Server만 참여한다.

 

4) 인증이 유효하다고 판단되면 Authorization Server 에서는 권한을 받을 수 있는 Authorization code를 반환한다.

Client는 Authorization code를 가지고 AccessToken 발급 요청을 한다. 

- redirect_uri 는 access token 을 반환받을 uri 를 말함

5) 인증이 끝나면 AccessToken을 반환한다.

권한을 받는 과정을 보면 Client 와 Authorization 만 참여를 한다. 권한을 탈취당할 위험을 줄인다. 

---

참고자료

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-OAuth-20-%EA%B0%9C%EB%85%90-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

🌐 OAuth 2.0 개념 - 그림으로 이해하기 쉽게 설명

https://www.youtube.com/watch?v=Mh3LaHmA21I 

https://tecoble.techcourse.co.kr/post/2021-07-10-understanding-oauth/

OAuth 개념 및 동작 방식 이해하기