- 인증은 누군가 또는 시스템이 실제로 그 누구인지 또는 시스템인지를 결정하는 과정이다.
- 사용자의 자격 증명 정보와 인증 서버의 자격 증명 정보를 비교하여 시스템에 대한 엑세스 권한을 제공한다.
- 돈을 인출하기 위해 은행에 간다고 했을 때, 은행원에게 통장과 도장 그리고 신분증을 제시하는 과정과 비슷
회원가입
=> 서비스 이용을 원하는 사용자는 서비스 가입 절차를 진행
=> 사용자의 아이디와 비밀번호를 데이터 베이스에 저장
=> 단 사용자의 비밀번호를 입력한 문자 그대로가 아닌 암호화를 진행 한 후 저장
로그인
=> 사용자가 회원가입 때 입력한 본인의 아이디와 비밀번호를 입력
=> 사용자가 ㅇ비력한 정보와 DB에 저장된 정보 비교
=> 정보가 일치하면 사용자 인증 정보를 사용자에게 전송
- 인가는 사용자에게 특정 리소스 또는 기능에 대한 액세스 권한을 부여하는 프로세스
- 사용자에게 권한을 부여하기 위해서 항상 인증 절차를 진행
- 인증 절차 후 조직의 관리자는 요청된 리소스에 대한 액세스 권한을 부여
- 클라이언트가 브라우저를 통해 웹 서버에 접속한 시점으로부터 브라우저를 종료하여 연결을 끝내는 시점 동안 클라이언트와 웹 서버가 논리적으로 연결된 상태
- 서버는 Session 정보를 저장하고 클라이언트에게는 Session을 구분할 수 있는 Session ID를 부여
- 클라이언트 Requset를 보낼 때 해당 Session ID를 함께 보냄으로써, 클라이언트의 상태를 확인
- 클라이언트의 컴퓨터에 저장되는 데이터 파일
- 이름, 값, 만료날짜/시간, 경로 정보 등으로 구성
- 하나의 도메인 당 20개를 가질 수 있으며, 각 4kbyte를 넘길 수 없음
- 서버에서는 HTTP Response Header에 Set-Cookie 속성을 이용하여 클라이언트에 Cookie를 제공하여 저장하게 함
- 클라이언트는 HTTP Request에 저장된 Cookie를 함께 전달하여 이전의 통신에서 사용된 정보들을 파악
- Cookie를 이용하여 로그인을 하지 않은 상태로 장바구니에 상품을 담을 수 있게 구현 가능
- 사용자별로 다른 정보를 표시하는 것이 가능하며, 사용자의 행도오가 패턴을 분석할 수 있음
장점
=> Session ID 자체에는 유의미한 개인정보가 없음
=> 서버에서 정보를 관리하기 때문에 데이터의 손상 우려에 대해 상대적으로 안전
=> 서버에서 상태를 유지하고 있으므로, 사용자의 로그인 여부 확인이 쉬움
=> 경우에 따라서 강제 로그아웃 등의 제재를 가할 수 있음
단점
=> 서버에서 모든 사용자의 상태르르 관리해야 되므로 사용자의 수가 증가 할 수록 서버에 가해지는 부하 증가
=> 사용자가 증가하여 서버의 Scale Out을 해야 할 때 Session 관리가 어려워 짐
- Token을 가지고 있으면 해당 서비스를 이용할 수 있는 권리가 있다고 간주
- 제한된 리소스에 대해 일정 기간 동안 접근할 수 있는 권한을 캡슐화
- TOKEN은 일반적으로 의미를 알 수 없는 임의의 문자열 형태로 사용자에게 발급
- 접근 할 수 있는 리소스의 범위와 접근 가능한 기간 또한 통제 가능
장점
=> Token을 사용자 측에서 저장하므로 서버의 메모리나 DB 등의 부담이 없음
=> 사용자의 상태 정보를 서버에서 관리하지 않기 때문에 서버의 Scale Out에 용이
=> Token의 만료 시간을 짧게 설정하여 안정성 증가
단점
=> 사용자의 로그인 여부 확인 및 강제 로그아웃 등의 제재를 가하기 어려움
=> 사용자가 임의로 토큰을 수정하거나 구조가 변경되게 되면 서버에서 확인할 수가 없음
=> Payload 부분에 사용자 식별을 위한 여러 정보들이 포함 되어 있어 Session Id의 길이보다 길어져 HTTP request 전송 데이터의 크기가 증가
인증과 인가는 회원가입, 로그인 등 클라이언트의 정보를 검증하는데에 주로 사용된다.
Session/Cookie와 Token의 장단점을 잘 비교하며 서비스에 따라 인증/인가를 적용하면 될 것 같다.
추후 백엔드를 공부할 때 유용한 자료로 활용되었으면 좋겠다.