luminous_dev
2025. 2. 4. 14:15
| 내용 | |
| 인증(Authentication) | 해당 유저가 실제 유저인지 인증하는 개념 ex) 스마트폰에 지문인식, 이용하는 사이트에 로그인 등 |
| 인가(Authorization) | 해당 유저가 특정 리소스에 접근이 가능한지 허가를 확인 ex) 관리자 페이지-관리자 권한 회원/비회원 여부에 따라 다른 권한을 받는 것 |
“웹 애플리케이션 인증”의 특수성
- 일반적으로 서버-클라이언트 구조 / 실제로는 아주 멀리 떨어져 있음
- Http 라는 프로토콜을 이용하여 통신 (비연결성(Connectionless) 무상태(Stateless))
리소스 절약, 서버 비용 절약 위해 다음을 실행
비연결성(Connectionless)
: 서버와 클라이언트가 연결되어 있지 않다는 것
: 서버는 실제로 하나의 요청에 하나의 응답을 내버리고 연결을 끊어버리고 있음
무상태(Stateless)
: 서버가 클라이언트의 상태를 저장하지 않음
: 기존의 상태가 없다고 가정하는 프로토콜을 이용해 구현
: 서버는 클라이언트가 직전에, 혹은 그 전에 어떠한 요청을 보냈는지 관심도 없고 전혀 알지 못함
Q. 근데 우리가 인터넷 사용할때는 이전의 정보들이 잘 있는것처럼 연속성있게 사용해왔는데요?
→ 개발자의 노력임
비연결성, 무상태 프로토콜에서 “유저가 인증되었다”라는 정보를 유지시켜야 한다는 과제를 어떻게 해결했는가?
인증의 방식 2가지
1. 쿠키-세션 방식의 인증
‘특정 유저가 로그인 되었다’는 상태를 저장하는 방식
서버는 인증과 관련된 최소한의 정보만 저장해서 로그인 유지
(그림 순서 설명)
1. 사용자가 로그인 요청을 보냄
2. 서버는 DB의 유저 테이블을 뒤져서 아이디 비밀번호를 대조
3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고
“세션 저장소”에 해당 유저가 로그인 되었다는 정보를 넣음
4. 세션 저장소에서는 유저의 정보와는 관련 없는 난수인 session-id를 발급
5. 서버는 로그인 요청의 응답으로 session-id를 내어줌
6. 클라이언트는 그 session-id를 쿠키라는 저장소에 보관 & 앞으로의 요청마다 세션아이디를 같이 보냄
(주로 HTTP header에 담아서 보냄)
7. 클라이언트의 요청에서 쿠키를 발견했다면 서버는 세션 저장소에서 쿠키를 검증
8. 만약 유저정보를 받아왔다면 이 사용자는 로그인이 되어있는 사용자
이후에는 로그인 된 유저에 따른 응답을 내어줍니다.
2. JWT 기반 인증 (JSON Web Token)
인증에 필요한 정보들을 암호화시킨 토큰
JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별
1. 사용자가 로그인 요청을 보냄
2. 서버는 DB의 유저 테이블을 뒤져서 아이디 비밀번호를 대조
3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고
유저의 정보를 JWT로 암호화 해서 내보냄
4. 서버는 로그인 요청의 응답으로 jwt 토큰을 내어줌
5. 클라이언트는 그 토큰을 저장소에 보관하고 앞으로의 요청마다 토큰을 같이 보냄
6. 클라이언트의 요청에서 토큰을 발견했다면 서버는 토큰을 검증
7. 이후에는 로그인 된 유저에 따른 응답을 내어줍니다.