본문 바로가기
Frontend/React

React 인증 방식과 개념

by Forsaken Developer 2023. 2. 22.
728x90
728x90

React 인증 방식과 개념

인증이 작동하는 원리를 이해하려면 인증의 필요성부터 이해해야 한다.

웹사이트에 인증이 필요한 이유는 보호해야 할 정보가 있기 때문이며 모든 사이트 이용자나 방문자가 모든 정보에 접근 권한을 가져선 안 되니 인증이 필요하다.

페이지 자체에도 접근 제한을 걸어야겠지만 인증된 사용자가 보낸 요청이 아니라면 API 엔드포인트로 전송된 요청이 성공할 수 없게 API 엔드포인트에도 접근 제한을 걸어야 한다.

API 엔드포인트에 접근 제한을 걸지 않으면 엔드포인트의 URL을 아는 사용자나 요청을 보내 다른 사람의 데이터를 바꿀 수 있기 때문이다.

일반적으로 인증은 2단계 절차를 거치는데 1단계는 사용자가 접근 허가를 받는 것이고 2단계는 접근 허가를 통해서 보호된 리소스에 요청을 보내는 것이다.

로그인 시에 자격 증명을 제공하면 데이터가 서버로 전송되고 서버에서 데이터베이스를 살펴 사용자의 아이디/비밀번호 조합을 확인하여 유효성이 검증되면 요청을 받은 백엔드 서버가 접근을 허가한다.

허가를 받으면 사이트의 특정 페이지에 접근할 수 있고 필요에 따라서는 접근 허가를 활용해 API 엔드포인트의 다른 보호된 리소스에 후속 요청을 보낼 수도 있다.

서버에 요청을 보내면 서버가 유효성을 확인하고 자격 증명을 검증해 후속 요청을 허가하거나 거절하고 받은 허가로 후속 요청을 할 수 있지만 단순히 ‘예, 아니오’만으로는 API 엔드포인트 같은 보호된 리소스에 접근할 수는 없다.

자격 증명을 받는 서버가 ‘예, 아니오’로만 응답한다면 허가를 받는 절차를 생략하고 보호된 리소스에 우리가 직접 ‘예, 아니오’ 요청을 보낼 수도 있다.

그러므로 인증은 단순한 ‘예, 아니오’보다 더 정교하고 복잡해야 한다.

그럴 때 쓰는 기법은 크게 2가지인데 서버 사이드 세션을 활용하거나 인증 토큰을 활용한다.

서버 사이드 세션

서버 사이드 세션은 전통적이면서도 훌륭한 인증 처리 기법이다.

사용자 접근을 허가한 서버가 허가를 받은 클라이언트, 즉 특정 사용자의 고유 ID를 저장한다.

따라서 인증을 거치는 모든 사이트 방문자의 고유 ID가 서버에 저장된다.

이 ID는 서버에만 저장되지 않고 클라이언트에게도 전송되어 서버의 응답은 단순한 ‘예, 아니오’가 아니라 고유 ID까지 포함한다.

서버와 클라이언트 모두 이 ID를 알고 있고 이 ID는 서버에 후속 요청을 보낼 때 함께 첨부된다.

서버가 ID를 알고 있으므로 ID를 위조할 수 없고 임의로 만든 ID는 서버가 못 알아보니 접근이 거부되고 후속 요청도 불가능하다.

그러나 이 방식에는 단점이 하나 있는데 백엔드와 프론트엔드의 결합이 긴밀하면 아무 문제 없지만 분리돼 있다면 이야기가 달라진다.

프론트엔드 앱은 서버 A로, 백엔드 앱의 REST API는 서버 B로 운영 중이라면 결합이 느슨해서 백엔드 API와 프론트엔드의 앱은 서로 독립적으로 작동할 것이다.

또는 여러 사이트에서 이용할 수 있는 API를 만든다면 이 역시 특정 프론트엔드에 긴밀하게 결합하지 못한다.

따라서 이런 경우에는 서버에 ID를 저장하면 안되며 서버는 이른바 무상태여야 한다.

그런 상황에서는 인증 토큰을 사용한다.

인증 토큰

기본 개념은 비슷하지만 중요한 차이가 있다.

사용자가 아이디와 비밀번호로 서버에 자격 증명을 보내면 서버가 그걸 데이터베이스에 저장된 이메일/비밀번호 조합과 비교해 유효성을 확인하는 것까지는 같다.

하지만 자격이 증명되면 서버가 인코딩된 아주 긴 문자열 허가 토큰을 생성한다.

서버가 특정 알고리즘을 사용해 사용자의 아이디를 비롯한 각종 데이터를 한 문자열로 인코딩하면 나중에 다시 개별 데이터로 디코딩할 수 있다.

토큰은 서버가 특정 알고리즘에 따라 생성하는데 이 때 서버만 아는 키를 사용해 데이터를 문자열로 해싱한다.

사용되는 키는 클라이언트는 모르고 서버만 알고 있으며 토큰은 서버에 저장되지 않고 클라이언트에게 다시 전송되지만 토큰을 생성하는 법은 서버만 알고 있다.

리액트 앱 같은 클라이언트는 이 토큰을 후속 요청에 첨부해 서버의 보호된 리소스에 보낸다.

서버는 세션 기반 기법과 달리 ID를 저장하지 않고도 자신이 생성한 토큰인지 확인할 수 있다.

토큰이 위조됐거나 다른 키로 생성됐으면 서버가 이를 감지하고 접근을 거부한다.

728x90
반응형

'Frontend > React' 카테고리의 다른 글

React 배포하기  (0) 2023.02.24
React lazy loading 개념과 사용 방법  (0) 2023.02.23
react router v6 변경 사항  (0) 2023.02.21
React 동적 라우팅과 중첩 라우팅  (0) 2023.02.19
react-router Link와 NavLink 사용 방법  (0) 2023.02.18

댓글