Authentication(인증)에 대하여 - sr-sig3/news-dashboard-backend GitHub Wiki
: 본인이 누구인지 확인(로그인)
ex. 웹사이트 로그인
=> "너는 철수구나"
: (인증된 사용자나 시스템이) 특정 리소스에 권한이 있는지 확인
즉, 인증 이후의 프로세스
ex. 웹사이트 로그인해서 특정 웹 페이지 접근
항목 | 인증 (Authentication) | 인가 (Authorization) |
---|---|---|
의미 | "너는 누구냐?" | "너는 이걸 할 수 있냐?" |
목적 | 사용자의 신원을 확인 | 권한을 확인하고 제한 |
예시 | 로그인(ID/PW, OTP, 지문 등) | 관리자만 글 삭제, 유료 사용자만 다운로드 |
처리 시점 | 항상 인가보다 먼저 | 인증이 성공한 뒤에 수행됨 |
결과 | 사용자 인지 아닌지 확인 | 권한이 있는지 확인 |
로그인 인증을 위해 쿠키와 세션 함께 사용
- Cookie
- 클라이언트의 "브라우저"에 저장되는 데이터
- 사용자의 인증 정보나 session ID 저장
<쿠키 저장 위치>
<쿠키 전달 방식>
- Session
- 서버 측에서 관리하며 로그인한 사용자를 식별하기 위한 기술
- 사용자가 로그인하면 서버 측에 인증 정보(ID, PW)와 session ID 저장
- 브라우저 마다 별도의 session ID 생성
- 세션 만료 시간 지나면 다시 session ID 생성
<동작 방식>
- 클라이언트 -> 서버 : 로그인 성공시, 서버에서 session ID 생성하여 서버 측 DB에 저장
- 서버 -> 클라이언트 : Session ID 전달하며 클라이언트는 쿠키 사용해서 저장
ex. Set-Cookie: sessionId=abc123; Path=/; Domain=example.com; - 클라이언트 -> 서버 : 요청시 쿠키로 Session ID가 함께 전달되며 서버 측에서 유저 정보와 맞는지 확인
- 서버 -> 클라이언트 : 문제가 없다면 로그인 유지 시키며 응답
<특징>
- 보안 Good(정보는 모두 서버에)
- 별도 DB에 저장하기 때문에 사용자가 늘어나면 서버에 부하
- 매번 DB 확인해야함
- 사용자가 새로운 장치로 접속할때마다 session ID 늘어남
- 서버에 부하가 생기는 세션 방식을 보완하기 위함
- 로그인 시 서버가 암호화된 토큰을 발급하고 이를 클라이언트가 저장하여 요청마다 포함하여 보냄
- JWT(JSON Web Token)이 널리 사용됨(JSON 형태)
<JWT 구조>
- "편지"라고 생각하기
- 구조 : header.payload.signature로 구성
- signature(서명)
- 서버 측에서 secret key를 가지고 있음
- 서버에서는 payload와 secret key를 사용하여 signature(서명) 만듦
- 클라이언트에서 보낸 JWT에서 아래 둘 비교하여 진위 판별
- JWT의 signature
- JWT의 payload와 서버측의 secret key로 만든 서명
<동작 방식>
- 로그인할 때 한번만 사용자가 있는지 확인하고 이후에 DB 접근 안 함
<특징>
- Stateless : 서버가 상태 저장하지 않음
- 보안 취약 : 토큰 탈취 시 위험
- 한번 발급된 JWT는 만료 시간전까지 무조건 유효
- 보완
- 만료 시간을 짧게
- access, refresh token 발급
JWT 생성해보기
https://jwt.io/