#로그인구현
🤓 What I Learned Today
유저 정보 입력 및 저장
[login]
- 유저가 id를 입력하고 id Input의
onChange이벤트 핸들러에 연결된 함수가 실행되서 함수에서 id Input의value를setId를 통해 id state에 저장 - 유저가 password를 입력하고 입력할 때 password Input의
onChange이벤트 핸들러에 연결된 함수가 실행되면 함수에서 password Input의value를setId를 통해 password state에 저장
[signup 또는 login 버튼]
(→ onClick 이벤트 핸들러에 연결된 함수가 실행.)
- [sing up] 버튼의
onClick이벤트 핸들러에 연결된 fetch메서드가 실행 - [login] 버튼의
onClick이벤트 핸들러에 연결된 fetch메서드가 실행
fetch로 서버에 요청 처리
버튼을 누르고 호출된 fetch 메서드가 호출될 때 첫 번째 인자인 api 주소에 요청!
- [sign up] -
signup api로요청할 때 fetch 메서드 body에 저장된 id, password를 담아서 요청 - [login] -
login api로요청할 때 fetch 메서드 body에 저장된 id, password를 담아서 요청
서버에서 인증/인가 실행
클라이언트에서 요청한 정보를 가지고 서버에서 유저 데이터 저장과 인증/인가 처리
- [sign up] - id, password가 선언해 둔 조건에 맞게 전송됐는지 확인. 조건에 맞으면 id, password를 서버에 저장. (대소문자, 숫자, 특수문자, 글자 수 등) 조건에 맞지 않으면 에러 메시지를 반환.
- [login] - 서버에 저장되어 있는 id, password랑 대조해서, 조건에 맞으면
access token(JWT)을 발급하고, 조건에 맞지 않으면 생성하지 않고 에러 메시지를 반환
**인증 과 인가?
인증이란 사용자의 신원을 검증하는 프로세스이며 ID와 PW를 통해 로그인하는 행위를 인증이라 할 수 있다.
인가는 인증 이후의 과정으로 인증된 사용자가 어떠한 자원에 접근 할 수 있는지를 확인하는 절차이다.
fetch로 서버에서 응답 처리
server에서 인증 / 인가 과정을 거친 후의 결과를 응답(Response)으로 보내줌
- [sign up]
- 통신에 성공했다면 JSON 형식을 객체로 변환하고, main 페이지로 URL을 변경
- 통신에 실패했다면 alert로 에러 메시지를 출력
- [login]
- 통신에 성공했다면 JSON 형식을 객체로 변환하고,
access token(JWT)받고 - 통신에 실패했다면 alert로 에러 메시지를 출력
- 통신에 성공했다면 JSON 형식을 객체로 변환하고,
HTTP의 stateless
웹 사이트는 HTTP 통신 위에서 동작한다. 모든 요청과 응답은 stateless 한 특성가진다. (서버에서 Client의 이전 상태를 기억하고 있지 않는 다는 뜻)
그렇다면 stateless한 HTTP 위에서 인증/인가는 어떠한 방식으로 이루어져있을까?
1.
Cookie
서버에서 사용자 브라우저로 전송하는 작은 데이터로 브라우저 서버에서는 받은 데이터(내가 만든 쿠키….)를 저장해 놓았다가 동일한 서버로 재요청 시 제공 받았던 데이터를 함께 전송한다.
로그인할때 서버는 아이디와 비밀번호를 쿠키에 담아 응답하고 이후 요청부터는 브라우저가 ID/PW를 Cookie에 담아 함께 보낸다면 사용자는 인증/인가를 위해 매번 ID와 PW를 입력할 필요가 없어진다.
인증/인가에 Cookie만을 사용한다는 것은 첫 인증 때 기존 로그인 정보를 Cookie 형태로 브라우저에 심고 매 요청마다 Cookie를 통해 로그인 정보를 함께 서버로 보내는 것으로 매번 자동으로 로그인을 하는 것
장점?
기존 로그인을 위한 정보를 사용하기 때문에 인증/인가를 위한 추가적인 데이터 저장이 필요 없고 또한 서버 대수를 늘리는 Scale out에도 크게 이슈가 없다.
단점?
사용자의 주요 정보를 매번 요청에 담아야 하기에 보안상의 문제
2.
Session
매번 로그인 정보를 요청에 담아 보내는 것은 보안상 문제가 생길 수 있다. 이러한 문제점에서 벗어나고자 나온 것이 Session이다.
Session은 고객의 주요 정보가 아닌, 단지 고객을 식별할 수 있는 값을 생성해 Cookie로 주고받는 다.
이러한 방식은 고객의 로그인 정보를 주고 받지 않아 이전 방식보다 보안상의 장점이 있지만, 사용자를 식별할 수 있는 값을 생성하고 서버에 저장해두어야하는 작업이 생기게 된다.
이때 생성되는 사용자 식별 값을 Session ID라 하고 어디에 저장하는가에 따라 2가지 방식이 존재
1.서버 내부에 Session 저장소가 있는 경우 위 방식은 다중 서버일 경우에는 문제가 있다.
매번 같은 서버로 요청이 가는 것을 보장하지 않는 다중 서버 환경에서 각 서버가 개별적인 Session 저장소를 가질 경우 Session ID가 저장되지 않은 곳으로 요청이 가면 사용자를 식별할 수 없다.
→해결하는 방법?
- Load Balancer를 통해 사용자를 식별하여 이전에 통신한 서버로 요청이 가도록 경로를 지정해주는 방법
- 다중 서버의 모든 Session 저장소를 동일하게 유지하는 방법
2.단일 Session 저장소를 두고 서버에서 저장소에 접근해 Session ID를 삽입하고 조회하기 때문에 다중 서버 환경에서도 단일 저장소가 감당해야 할 부하가 있다.
3.
Token
기존 로그인 정보를 그대로 사용하지 않으면서도 서버에서 사용자 식별 값을 저장/관리하지 않아도 되는 방법
Token은 사용자를 인증할 수 있는 정보가 숨겨진 암호화된 Access Token을 발행하고, 인증이 필요할 때마다 서버에 Token과 함께 요청을 보내게 된다.
서버는 저장된 데이터가 아닌 Token 해독을 통해 Token 속에서 사용자를 식별할 수 있는 정보들을 알아내고 이를 바탕으로 인증/인가가 진행
JWT 저장 장소
Cookie와 Session의 경우 Set-Cookie를 통해 고민 없이 브라우저 Cookie 저장소에 저장(JWT의 저장 장소로는 Local Storage와 Cookie가 선택지)
🤔 Challenges Experienced
이번 과제에는 로그인 기능구현과 회원가입 기능구현이 추가 되었다.겉보기에 사이트가 돌아가게 하는 것이 이제 막 익숙해졌는데 여기에다가 백엔드와의 소통과 서버로 정보를 주고 받는 개념이 익숙하지 않고 너무 어려운 느낌이다.
흐름을 이해하기 위해 개념과 기능구현을 useState 로 UI를 만들고 어떻게 구현 할지 코드만 짜보았다. 여기에서 더 알아봐야 할 개념은 HTTP의 특징과 백앤두 서버와 어떻게 request ,response 할지 좀 더 공부해야겠다.
🚀 Code Snippets
1.먼저 home 화면에 로그인을 페이지로 이동할 수 있는 버튼,링크를 만들고
로그인을 해야만 볼 수 있는 조건을 가진 detail 페이지 이렇게 있어야 한다.
2.detail 페이지 혹은 로그인 을 누르면 로그인을 할 수 있는 페이지로 이동!
- 로그인을 하면 메인페이지인 home 으로 이동하고 로그아웃으로 바뀐다.
- 이제 디테일 페이지를 볼 수 있게 됐다.
state 를 이용해 간단히 로컬환경에서 확인 할 수 있는 간단한 흐름잡기 위해서 만들어보았다.
이제 이것을 백엔드 서버와 통신해야 하는데 ....이부분을 좀 더 알아봐야겠다.
