사용자가 누구인지를 확인하는 과정
로그인 요청 시 유저가 어떤 사람인지 확인하는 것
인증된 사용자가 사용할 수 있는 기능의 범위를 정하는 것
유지할 상태가 없는 웹 앱에서 인증을 구현하는 가장 간단한 방법
모든 HTTP 요청에 id/pw을 같이 보내는 것
최초 로그인 후 HTTP 요청 헤더의 Authorization 부분에
Basic ID:PW 과 같이 세미콜론으로 이어붙인 후 Base64로 인코딩한 문자열을 보낸다.
서버는 디코딩해 아이디와 비밀번호를 찾아낸 후 저장된 정보와 비교해 일치 여부에 따라 요청을 처리한다.
단점
토큰 : 사용자를 구별할 수 있는 문자열
최초 로그인시 서버가 내부 로직에 따라 생성해 반환하면 클라이언트는 이후 요청에 id/pw 대신 토큰을 계속 넘겨 자신이 인증된 사용자임을 알린다.
Bearer
요청 해당에 Authorization: Bearer [Token]과 같이 명시한다.
서버는 어떠한 형태로든 인증을 해야한다.
basic 방식과 비교 시
JWT
전자 서명된 토큰을 이용하면 스케일 문제 또한 해결할 수 있다
그 중 하나가 JSON Web Token
구성
{header}.{payload}.{signature}
Header
typ: 토큰의 타입, alg: 토큰 서명 발행 시 사용된 해시 알고리즘의 종류
Payload
sub: subject,토큰의 주인, ID 처럼 유일성을 지녀야함.
iss: Issuer, 토큰 발행 주체, 페북이면 페북, 구글이면 구글
iat: issed at, 토큰 발행 날짜,시간
exp: expiration, 만료시간
Signature
Issuer가 발행한 서명으로 유효성 검사에 사용
전자서명이란
{header}.{payload}와 시크릿키를 이용해 해시 함수를 돌린 암호화한 결과값
시크릿키는 개발자가 임의로 정한 문자열을 의미한다.
과정
최초 로그인시 입력된 id,pw와 서버에 저장된 id,pw을 비교해 인증
인증된 사용자인 경우 사용자의 정보로 header,payload 작성 후 시크릿 키로 전자 서명한다.
결과값을 signature에 붙여 Base64로 인코딩 후 반환
후에 이 토큰으로 리소스 접근 요청 시
디코딩 -> JSON을 구조에 맞게 파싱
헤더,페이로드 와 자신의 시크릿 키로 서명을 생성하고 비교해 토큰 유효성 검사
또한 HTTPS 사용 필요