티스토리 뷰

● Session-based Authentication

1. Session-based Authentication
- 사용자의 세션 정보를 저장해서 로그인 기능을 구현하는 방법
- Session 방식은 전통적이고 범용적으로 사용되는 인증방식이다.
- 쉽게말하면 아래와 같은 방식이다.

1. 사용자가 로그인 했었다는 정보를 서버의 메모리에 기록(= session을 저장)
2. 사용자가 로그인이 필요한 페이지를 요청을 하면  ex) 마이페이지
3. session을 뒤져서 해당 사용자가 로그인했다는 정보가 나오면 통과

cf) session = 사용자가 언제 어디서 로그인 했는지 등의 정보를 담은 자료
ex) "garden 사용자가 19시에 로그인했다."  →  이런 정보를 서버 메모리에 저장해둔다.


- 조금 더 자세하게 알아보자
1. 사용자가 로그인 시 제출한 ID&PW가 DB에 저장된 회원정보와 일치
- 이때 서버는 sessionstore에 session을 하나 만들어 저장한다.

2. 이때 로그인한 유저마다 각각 유니크한 Session ID를 발급한다.
- 로그인한 사람이 여러명일 수 있으니 유니크한 Session ID를 발급해 구분지어준다.
- (Session ID = abc123)라고 해보자

3. 발급한 Session ID를 cookie에 담아서 고객 브라우저에 전송한다.
- Session ID는 고객과 서버 둘 다 보관하기에 cookie에 담아서 고객에게 보내주는 것이다.
- 여기서 cookie란 브라우저에 있는 작은 문자데이터 저장공간이다.


- 여기까지가 session 로그인 기능 구현 전부이다.
- 그럼 이번에는 사용자가 로그인이 필요한 페이지를 요청한 경우 해당 사용자가 적법하게 로그인 했었는지 검사해보자

 

1. 사용자가 로그인한다. 
- ID / PW를 서버로 전송
- 서버는 전송된 ID / PW 세트가 DB에 존재하면 Session ID를 만들어준다.
- 그 후 Session ID 들을 담을 변수나 미리 마련한 DB 공간에 발급된 Session ID를 저장한다.
- 이때 변수나 DB 공간을  Session Data라고 한다.
cf) 저장은 DB에 할 수도 있고 서버 메모리(변수)에 할 수도 있다.
- 그 후 Session ID 를 cookie에 담아서 사용자의 브라우저에 cookie를 강제로 저장시킨다.
 
2. 사용자가 마이페이지를 요청
- /mypage를 달라고 request하면 서버는 response.render() 해주기 전에 일단 막는다. 
- why? 요청한 사용자가 이전에 로그인을 했던 사람인지 알아야하니까
- 물어보는 과정은 아래와 같다.

3. cookie에 Session ID가 포함되어있는지 검사
- 원래 사용자가 페이지를 요청할 때 마다 자동으로 쿠키가 서버로 전송된다.
- 그러면 서버는 cookie에 기록된 Session ID를 (서버 메모리 or DB에 저장된 Session ID)와 비교해서 일치하면 통과시킨다.

4. 서버는 마이페이지를 render 해준다.
- 사용자의 이름, 나이, 성별 등의 DB 정보가 필요하다면 Session Data를 참조해 해당 정보를 DB에서 꺼내온다.


JSON Web Token(JWT)

Token 방식은 Session Data를 서버에 저장하지 않는다.
- 대신 마이페이지를 열람할 수 있는 열쇠(토큰)를 사용자에게 쥐어주는 것이다.
- 그렇기에 해당 열쇠(토큰)에는 session 방식보다 더 많은 정보들이 들어간다.

1. 사용자가 로그인 시 제출한 ID&PW가 DB에 저장된 회원정보와 일치
- 이때 서버는 Token 하나를 만들어 고객 브라우저로 보내준다.
- Token은 암호화된 긴 문자열로써 과거 사용자 로그인 여부, 아이디는 무엇인지 등의 정보들을 넣을 수 있다.
- 단, 위조가 불가능하도록 특별한 서명이 추가된다.
- 이러한 Token cookie나 localStorage에 저장된다.

2. 사용자가 마이페이지를 요청
- /mypage를 달라고 request하면 서버는 response.render() 해주기 전에 일단 막는다. 
- why? 요청한 사용자가 이전에 로그인을 했던 사람인지 알아야하니까
- 이때 필요한 과정이 Token 검사이다.

3. 서버는 토큰을 검사
- 사용자가 /mypage 요청시 함께 보낸 Token이 적법한지 검사한다.
cf) 고객이 페이지 방문시마다 Token이 서버로 보내지도록 미리 장치를 추가해야한다.
- 유통기한, 서명 여부, 블랙리스트에 등록된 토큰 여부 등을 검사해 문제가 없으면 마이페이지로 통과 


- 기본적인 Token 구현은 매우 간단하다.
- 또한 서버는 Session Data 등을 (메모리 혹은 DB)에 저장해둘 필요가 없으니 서버 스케일링시 큰 문제가 없다는 장점이 있다.
- 물론 단점과 보안상 취약점도 있다.
- 과거 로그인 여부에 대한 정보 전체를 서버는 가지고 있지 않고 사용자만 가지고 있게 하는 것 자체가 보안상 문제가 될 수 있다.
- 만약 JWT 정보를 제 3자가 훔쳐 자유롭게 로그인이 가능하다면 이는 큰 문제가 될 수 있다.
- 이러한 문제 방지를 위해 stateful JWT 라고 부르는 "어떤 사람이 언제 로그인했는지"를 서버에 저장해두는 방식이 있는데 이 중 하나가 refresh token 방식이다.
- 근데 이거는 session 방식과 기능상 큰 차이가 없다.


OAuth(Open Autentication)

- 해당 방법은 쉽게말하면 "페이스북이나 구글 계정으로 로그인하기"이다.
- 사용자의 페이스북, 구글 등의 계정 정보를 불러와 그것을 가지고 가입을 승인시켜주는 방법이다.

1. 사용자가 '페이스북으로 로그인' 방식 선택
- 페이스북 팝업이 뜬다.
- "~~~ 사이트에 본인의 페이스북 이름, 아이디 제공을 승인하시겠습니까?" 라는 알림이 뜨면 승인을 누른다.

2. 페이스북은 로그인 하려는 사이트의 server.js에게 해당 사용자의 이름, 아이디 정보 등을 보내준다.

3. 받은 페이스북 정보를 바탕으로 session이나 Token을 만들어준다.
- 받은 정보를 DB에 저장해서 회원 목록을 만들거나 이와 동시에 session date를 만들어주면 된다.
- server.js에 적절하게 코드를 잘 짜면 된다.


4. 사용자가 마이페이지를 요청
- /mypage를 달라고 request하면 서버는 response.render() 해주기 전에 일단 막는다. 
- why? 요청한 사용자가 이전에 로그인을 했던 사람인지 알아야하니까

5. 서버는 session이나 Token을 검사
- 3번에서 session을 만들었다면 session이 있는지 검사
- 3번에서 Token을 만들었다면 Token이 적절한지 검사
- 검사 후 통과되면 마이페이지를 response.render()


- OAuth는 PW를 취급 안해도 된다는 장점 때문에 관리도 편하고 사용자도 편리하게 로그인할 수 있다.
- 단점은 구글이나 페이스북이 아래와 같은 사태가 발생하면 OAuth로 로그인하는 사이트도 로그인이 불가능해진다.

1. OAuth를 중단하거나
2. 방법을 수정하거나
3. 페이스북 API 서버 다운으로 접속이 불가능
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31
글 보관함