[Project] 클라이언트와 서버 양 입장에서 로그인 과정 이해하기

이해를 목적으로 한 포스팅..... ! 출처는 아래 링크이다.

클라이언트와 서버 양 입장에서 로그인 과정 이해하기 (feat. session, JWT,소셜로그인)

1. Session 방식

서버에서 사용자의 세션 데이터를 저장해서 로그인 기능을 구현하는 방법

- 프론트와 서버 각각의 역할

1. [프론트] 프론트 쪽에서 로그인 페이지에서 아이디, 비번을 서버로 POST함

  a. [서버] 서버는 기존에 회원가입을 한 사람이면 서버에서 세션 아이디를 만들어줌

  b. [서버] 세션 아이디를 담을 변수, DB 공간을 마련해 거기 저장 (세션 데이터라고 부름)

  c. [서버] 그걸 쿠키라는 것에 포션해서 고객 브라우저에 그 쿠키를 강제 저장시킴

2. [프론트] 클라 쪽에서 /mypage(로그인 해야만 들어갈 수 있는 페이지)를 요청

(* 여기서 클라는 클라우드인가..?)

  a. [서버] 서버는 해당 요청을 받으면 일단 로그인 했는지 여부를 확인해야 함

  b. [서버] 쿠키에 세션 아이닥 포함되어 있는지 검사

  c. [서버] 만약, 있으면 통과시켜주고 그 과정에서 회원의 이름, 나이, 성별 등의 DB정보가 필요하면 꺼내옴

2. JSON Web Token 방식

세션 데이터를 서버에 저장하지 않고, 마이페이지를 열람할 수 있는 열쇠(토큰)을 사용자에게 쥐어줌. session 방식보다 그 열쇠에 더 많은 정보들이 들어감.

- 프론트와 서버 각각의 역할

1. [프론트] 프론트는 로그인 페이지에서 아이디, 비번을 서버로 POST함

  - [서버] 그 아이디, 비번이 DB에 저장된 회원정보와 맞다면 서버는 Token 하나를 브라우저로 보냄 -> 여기서 Token은 긴 암호화 된 문자열로, 사용자가 로그인 했었는지, 아이디는 무엇인지 이런 정보들 넣을 수 있으며, 위조가 불가능하도록 특별 서명이 추가됨.

2. [프론트] 해당 토큰은 프론트 딴에서 로컬스토리지에 저장 or 쿠키에 저장(만료 기한이 있는 key, value 형태의 저장소)

3. [프론트] 클라 쪽에서 /mypage(로그인 해야만 들어갈 수 있는 페이지)를 요청할 때 해당 토큰을 헤더에 붙여서 POST(로컬 스토리지에 있는 정보 or 쿠키에 있는 정보)

  - [서버] 서버는 해당 토큰이 적법한 지 검사해서 이상이 없으면 응답함

- 단점

로그인 했는지에 대한 정보 전체를 서버가 갖고 있지 않고, 사용자가 갖고 있게 하는 것 자체가 보안상 좋은 방법이 아님. 그 대안으로 나온 것이 stateful JWT이다. "어떤 사람이 언제 로그인 했는지"를 서버에 저장해두는 방식 => refresh token

 

⭐️ refresh token방식 

(* 다시 한 번 확인해야할 부분)

1. [프론트엔드] ID와 비밀번호를 준다.
2. [백엔드] ID와 비밀번호를 검증하고 AccessToken과 RefreshToken, AccessToken의 만료시간을 반환해준다. 이 때 생성한 RefreshToken은 DB에 {ID,RefreshToken}으로 저장한다.
3. [프론트엔드] 반환받은 AccessToken을 매 api 호출마다 헤더에 붙여서 전송한다.
4. [백엔드] api호출시 헤더의 AccessToken을 확인하고 유효한지, 만료기간이 지났는지를 체크 후 api를 동작시킨다.
5. [프론트엔드] AccessToken의 만료 기간이 지나거나, 30초 미만으로 남았다면, 백엔드에 RefreshToken을 붙여 Reissue 요청을 보낸다.
6. [백엔드] Reissue요청이 들어올 경우, RefreshToken이 DB에 있는 것인지 확인한 후, 맞다면 AccessToken과 새로운 AccessToken 만료 시간을 반환한다.
7. [프론트엔드] Reissue결과 반환된 AccessToken과 만료기간을 저장하여 다음 api호출에 사용한다.

https://donologue.tistory.com/397   아래 링크를 통해서 더 구체적으로 봐야할 것 같다.

Access Token + Refresh Token JWT 인증

 

3. Open Authentication 방식

소셜 로그인이 이에 해당함

- 프론트와 서버 각각의 역할

1. [프론트] 프론트 쪽에서 네이버 로그인 버튼을 제공해 네이버로부터 유저 이름, 아이디 정보를 받아서 그정보를 서버로 POST

  a. [서버] 서버에선 이 사람의 이름, 아이디 정보를 받아서 세션이나 토큰을 만들어줌

2. [프론트] 클라 쪽에서 /mypage(로그인 해야만 들어갈 수 있는 페이지)를 POST

  a. [서버] 세션 방식을 쓴 경우) 서버는 세션이 있는지를 검사

  b. [서버] JWT방식을 쓴 경우) 클라 쪽에서 온 토큰이 적법한 지를 검사

 

 

 

[참고]

https://merrily-code.tistory.com/193   

클라이언트 인증 구현으로 "세션 기반 인증 방식"과 "토큰 기반 인증 방식"을 구분하여 설명해놓은 이해가 잘 되는 포스트이다

클라이언트 인증 구현하기 : 인증이란 무엇인가?

 

https://tansfil.tistory.com/58