이번 포스팅에서는 어플리케이션에서 빼놓을 수 없는 기능인 로그인과 로그아웃을 구현하기에 앞서 Authentication(인증)이라는 것에 대해 정리하고 넘어가보려한다.
위 그림처럼 클라이언트는 로그인 폼을 통해 사용자 증명을 포함한 Request를 전송하게 된다.
이러한 요청을 받은 서버는
- 해당 자격 증명의 유효성 검증
- 필요한 경우 새로운 사용자 생성
등의 작업을 진행하게 된다.
만약, 자격 증명이 유효한 경우 (ex. 올바른 이메일, 비밀번호 조합) 서버의 자원에 대한 접근을 허가한다는 응답을 보내줘야한다.
하지만, yes / no 라는 답변만으로는 충분하지 않다.
서버가 'yes'라고만 답하면 나중에 클라이언트가 서버에 다시 요청을 보낼 경우, 과거에 접근 승인을 받을 때 사용한 정보를 다시 붙여서 사용하면 되기 때문에 허가를 받은 것 처럼 조작할 위험이 있다.
서버는 단순히 yes / no 가 아니라 그 이상의 서버에서 검증한 어떤 것을 회신해 주어야 한다.
(ex. 과거에 서버에서 허가를 받았다는 증거)
이를 구현하는 방법은 대표적으로 두 가지가 있다.
Server-side Sessions(서버 측 세션)
- 대중적인 솔루션
- 프론트와 백엔드가 분리되지 않은 풀스택 앱에서 자주 사용됨
(하지만 리액트는 분리되어 있음 → 리액트에는 부적합) - 백엔드와 프론트엔드 사이에 긴밀한 결합이 필요
- 백엔드가 클라이언트 관련 정보를 반드시 저장해야하기 때문
원리
- 사용자 로그인 후 인증
- 서버에 고유 식별자를 저장
- 기본적으로 'yes'를 서버에 저장
- ID를 이용해 그 대답을 특정 클라이언트와 연결
- ID를 다시 클라이언트에게 전송
- 클라이언트는 이후 요청에서 해당 ID를 전송하여 자원에 접근
- ID는 'yes'라는 대답과 연동되어 서버에 저장되어 있으므로 서버는 이 클라이언트가 보호된 자원에 접근할 권한이 있는지 확인 가능
Authentication Tokens(인증 토큰)
- 분리된 백엔드 API
- 클라이언트와 긴밀히 결합되어 있지 않음
- 클라이언트 측 정보를 저장하지도 않음
- 토큰 : 알고리즘에 따라 생성된 문자열, 몇 가지 정보를 포함함
원리
- 사용자가 인증받은 다음(사용자가 유효한 자격증명을 전송한 뒤) 허가 토큰을 생성, 하지만 저장하지는 않음
- 백엔드에서 토큰을 생성하고 다시 클라이언트에게 전송
(토큰을 생성한 백엔드만이 해당 토큰의 유효성을 확인하고 검증할 수 있음 - 이후 다시 클라이언트가 백엔드에 요청을 보낼 때 해당 토큰을 요청에 첨부
- 백엔드는 토큰을 살펴보고 검증하고 이 토큰이 백엔드에서 만들어진 것인지 확인
- 유효한 토큰이라는 것이 확인될 경우
- 보호된 리소스에 대한 접근이 승인됨
어제보다 더 나은