728x90
반응형
인프런 "모든 개발자의 실무를 위한 필수 기본기 클래스" 강의를 듣고 정리한 내용입니다.
사용자가 있는 서비스의 필수 기능인 인증에 대해 알아보자!
쿠키와 세션
- HTTP 프로토콜의 특징으로 비연결성(Connectionless)와 무상 태성(Stateless)이 있다. 비연결성은 한 번의 HTTP 통신으로 요청과 응답이 오간 이후에 통신을 끊는다는 것이며, 이로 인해 통신과 관련된 상태는 남지 않는다(Stateless).
- 예를 들어, 사용자가 로그인 요청을 한 뒤 응답을 받았다고 하더라도, 다음 요청에 이렇게 로그인된 정보는 통신 어디에도 남지 않는다. 따라서 서버 입장에서는 네트워크 요청이 왔을 때 이 요청이 어떤 사용자의 요청인지 알 수 없다.
- 이렇게 상태 값을 가지지 않는 HTTP 통신 환경의 문제를 세션과 쿠키를 활용해서 해결할 수 있다.
- 세션과 쿠키는 웹 브라우저 환경에서 국한된다.
쿠키
- 쿠키는 웹 서버와 통신 과정에서 특정 정보를 저장하기 위한, Key - Value 형태의 유효기간을 가진 데이터이다.
- 과정
- 웹 서버에서는 클라이언트(웹 브라우저)에게 특정 데이터를 남기고 싶을 때 응답 HTTP 헤더에 Set-Cookie: 데이터를 기록한다.
- 브라우저는 자동으로 HTTP 헤더의 쿠키 정보를 읽고 웹 서버의 도메인에 매칭 해서 저장한다.
- 나중에 웹 서버에 HTTP 요청을 날리게 되면 자동으로 쿠키를 헤더에 담아서 전송한다.
- 브라우저에는 다양한 종류의 데이터를 저장할 수 있는 공간을 제공한다. 쿠키를 저장하는 공간 이외에도 로컬 스토리지, 세션 스토리지 등이 있다.
- 쿠키는 도메인(웹 사이트) 별로 쿠키를 다양하게 둘 수 있다.
- 쿠키 사용
- 서버 세션 관리 - 인증 관련
- 트래킹 (행동, 패턴 분석)
- 사용자 개인화 - 광고
세션
- 세션은 클라이언트와 서버 간의 네트워크 연결에 대한 정보를 담고 있는 객체이다.
- 세션은 서버 쪽에서 관리하는 객체로, 클라이언트와의 연결에 대한 정보를 담는다. 이때 세션을 저장하기 위해선 별도의 세션 스토리지를 구현하곤 한다.
- 일반적으로 세션을 사용해서 HTTP 통신을 하는 경우 아래와 같은 흐름을 따른다.
- 클라이언트가 서버와 연결을 시도하면 서버는 해당 연결에 대한 정보를 세션 저장소에서 찾는다.
- 세션 저장소에 정보가 존재하지 않는다면 새로운 세션을 만들고 저장한다.
- 클라이언트에게 생성된 세션 정보를 쿠키 혹은 다른 방식으로 넘긴다.
- 클라이언트는 해당 정보를 저장하고 있다가, 이후 요청에 세션 정보를 포함하여 요청을 보낸다.
- 일반적으로 서버에서는 세션을 관리할 때 ID로 관리하고, 접속 시간에 제한을 두곤한다.
- 세션은 일반적으로 사용자에 대한 식별이 필요할 때 사용한다. 로그인뿐만 아니라 동시 접속 탐지, 접근 기록 수집 같은 다양한 곳에 세션을 활용할 수 있다.
쿠키와 세션의 차이
- 가장 큰 차이는 인증에 대한 정보를 어디에 저장하느냐에 있다.
- 쿠키는 클라이언트 쪽에 저장한다. 즉 인증 절차에 대한 모든 정보가 클라이언트에 저장한 쿠키에 있다.
- 세션은 서버 쪽에 저장한다. 즉 모든 정보가 서버 쪽에서 관리하는 별도의 세션 저장소에 있다.
- 세션과 쿠키는 서로 대립하는 관계가 아니다. 쿠키는 브라우저에 특정 데이터를 저장하는 방식이지만, 세션은 클라이언트/서버 구조에서 연결 정보(객체)를 저장하는 방식이다.
- 보통 세션과 쿠키는 함께 사용한다. 세션 쿠키 사용해서 서버 쪽에서 세션 객체 만들어서 어떤 연결에 대한 정보를 담고 있으면, 쿠키 형식으로 브라우저한테 쏴준다. (setCookie를 헤더에 넣는 것). 그것을 브라우저 쿠키에 저장하는 것이다.
📝 정리
- 쿠키는 브라우저가 사용하는 임시저장소 중 하나로 Key-Value 형태로 데이터를 담는다.
- 세션은 클라이언트와 서버 간의 네트워크 연결에 대한 정보를 담고 있는 객체로, 서버에서 생성하고 관리합니다. 쿠키와 마찬가지로 보통 Key-Value 형태로 데이터를 담는다.
- 이 둘은 대립된 관계라기보단, 모두 활용하여 인증을 구현하게 된다.
사용자 인증 (Authentication)
서비스를 이용하는 사용자를 식별하는 기술을 인증 (Authentication)이라고 한다.
대표적인 인증 방식으로 세션 방식과 토큰 방식이 있다. 인증 방식에 대해 알아보자 !
인증 방식
계정 정보를 클라이언트에서 저장하기
- 계정 정보를 클라이언트에서 저장한 후 서버에 보내주는 방식. 간단하게 구현할 수 있다는 장점이 있다.
- 웹 브라우저에서는 계정 정보를 쿠키 저장소에 저장하여 인증을 간단하게 구현할 수 있다.
- 쿠키를 사용하는 방법
- 먼저 사용자는 로그인 페이지에서 계정 정보를 요청 메시지에 담아 서버에 요청을 보낸다.
- 그럼 서버는 이 정보를 받아 등록된 사용자임을 확인하고, 응답 메시지에 브라우저 쿠키에 위 정보를 응답 헤더에 인코딩을 하여 인증 정보를 담는다.
- 응답을 받은 클라이언트는 이 데이터를 브라우저 쿠키에 저장한다.
- 클라이언트는 서버로 요청을 보낼 때마다 이 쿠키를 함께 보내면, 서버에서는 해당 쿠키 정보를 디코딩해서 데이터베이스를 통해 인증을 진행한다.
- 이 방법으로, 우리는 매번 요청에 계정 정보를 담지 않아도 된다. 하지만 브라우저의 쿠키에 유저의 인증 정보가 그대로 남아있다는 점은 보안에 취약하다. 또한 서버에서는 요청에 포함된 쿠키를 계속해서 데이터베이스와 통신해야 하기 때문에 자원 낭비 및 성능 저하로 연결될 수 있다.
쿠키만으로도 충분한 경우
위 방법처럼 쿠키를 잘 활용하는 경우도 있다. 딱히 계정 정보와, 인증이 필요 없는 경우다. 대표적으로 쇼핑몰의 장바구니 기능이 있다. 보통 로그인을 하지 않아도(비회원으로) 장바구니에 물건 담기가 가능하다. 이런 시스템은 별도의 인증을 거치지 않지만, 브라우저에 담긴 쿠키로 개별 회원들을 어느 정도 구분한다. 이렇게 쿠키는 꼭 인증을 목적으로 쓰이지 않고, "임시 저장소"로서 폭넓게 사용된다.
세션 기반 인증
- 보통 인증을 구현할 때 인증 정보를 담을 수 있는 세션을 많이 활용한다.
- 세션 사용 과정
- 사용자는 쿠키를 사용하는 때와 똑같이 로그인 페이지에서 계정 정보를 다음처럼 요청 메시지에 담아 서버에 요청을 보낸다.
- 서버는 이 계정 정보를 받아 유효한 계정인지 확인한 후, "세션"이라고 하는 객체를 만들어 유저 정보와 접속 시간 등 연결에 대한 정보를 이 객체에 담는다. 그리고 세션을 세션 저장소에 저장한다.
- 그리고 응답 헤더에 다음처럼 생성한 세션 ID를 담아 클라이언트에게 응답한다.
- 응답을 받은 클라이언트는 이 데이터를 마찬가지로 브라우저 쿠키에 저장한다.
- 이제 클라이언트와 서버는 그대로 드러나는 세션 ID를 주고받게 되고, 서버는 요청을 받을 때마다 세션 저장소에서 세션 ID를 찾고, 유효한 세션 ID인지 확인한다. 만약 유효하다면 인증에 성공하는 것이고, 유효하지 않다면 인증에 실패한 것이다.
- 장점
- 계정 정보를 브라우저의 쿠키에 그대로 노출하지 않는다.
- 세션의 유효기간을 설정할 수 있기에 보안과 다양한 기능(동시 접속 차단 등)을 구현할 수 있다.
- 데이터베이스의 부하를 줄일 수 있다.
- 다만 인증에 필요한 데이터들을 서버 혹은 별도의 세션 서버에서 관리하기 때문에 서버에 부하가 생기게 된다. 실제로 대규모 서비스를 운영하기 위해선 세션 저장소를 체계적으로 관리하는 일도 중요하다.
토큰 기반 인증
- 세션 방식과 함께 많이 사용되는 인증 방식으로 토큰 인증(Token Authentication) 방식이 있다.
- 토큰은 별도의 저장소를 사용하지 않고, "토큰"이라고 하는 하나의 문자열에 인증에 필요한 데이터를 모두 담는 방법이다. 토큰은 여러 종류가 있으나, JWT(Json Web Token)이 가장 흔하게 사용된다.
- 토큰 사용 과정
- 사용자는 로그인 페이지에서 계정 정보를 다음처럼 요청 메시지에 담아 서버에 요청을 보낸다.
- 서버는 이 계정 정보를 받아, 유효한 사용자인지 확인한 후 다음처럼 유저 정보와 인증에 필요한 데이터를 문자열로 인코딩한다. (이 문자열을 토큰이라 한다.)
- 토큰은 인증에 필요한 정보를 담아 암호화된 문자열인데, 이 문자열을 복호화하면 원본 데이터를 얻을 수 있다.
- 서버는 응답 메시지에 위 토큰을 담아 응답하고 클라이언트는 해당 토큰을 특정 저장소에 저장한다.
- 클라이언트가 토큰을 포함하여 요청했을 때, 서버에서는 토큰을 복호화(복호화 키를 서버에서 갖고 있어 서버에서 해야 함)하여 사용자를 확인합니다. 만약 올바르지 않은, 위변조 된 토큰이라면 복호화되지 않는다.
- 이 방법은 세션처럼 별도의 세션 저장소가 필요하지 않기에 상대적으로 구현이 간편하다. 인증 로직(토큰 암호화와 복호화)을 서버에 잘 구현해두면 된다.
- 하지만 토큰에 많은 데이터를 저장할수록 토큰이 커지면서 네트워크 통신 비용이 비싸진다. 또한 한 번 발급된 토큰에 대해서는 중간에 폐기할 수 없다는 단점도 존재한다.
결국 세션과 토큰 방식의 차이는,
세션은 별도의 저장소에서 세션들을 관리하고 대조하는 방식이며 토큰은 암호화, 복호화 방식으로 별다른 저장소 없이 인증을 진행하는 방식이다. 서로 장단점이 있으니 상황에 맞게 사용해주면 된다.
인가
- 인가(Authorization)는 인증을 마친 사용자가 요청에 대해 유효한 권한을 가지고 있는지 확인하는 작업이다.
- 어떤 자원에 대해 접근을 사용자의 권한(Role)에 따라 다르게 설정해주는 것이 중요하다.
📝 정리
- 인증은 사용자가 등록된 사용자인지 확인하고 식별하는 작업이다.
- 현대에는 인증 방식으로 쿠키/세션, 토큰 방식을 많이 활용한다.
- 쿠키/세션 인증방식은 세션이라는 객체로 인증하는 방식으로 세션 ID를 헤더에 담아 클라이언트/서버가 주고받는다. 세션을 직접 관리하기에 다양한 인증 처리(동시 접속 차단, 유저 트래킹 등)를 구현할 수 있다. 대표적인 웹 서비스의 인증 방식이다.
- 토큰 인증 방식은 유저 정보를 토큰이라고 하는 암호화된 문자열로 만들어 이를 주고받으며 인증하는 방식이다. 웹뿐만 아니라 모바일 등 다양한 환경에서 쓰이도록 범용적이다. 별다른 저장소가 필요하지 않기에 서버를 스케일 업해도 문제가 되지 않는다.
- 인가는 인증이 완료된 사용자가 요청에 대해 유효한 권한을 가지고 있는지 확인하는 작업이다.
💡 더 공부하면 좋은 내용들
- OAuth
- SNS 로그인은 서비스를 이용하는 사용자들이 비밀번호 같은 정보를 따로 제공하지 않고 다른 서비스(OAuth를 제공하는 서비스들)의 인증 정보로 로그인을 할 수 있는 방식. 이때 외부 서비스에서 본 서비스의 계정을 활용할 수 있도록 하는 방식(표준)을 OAuth라고 한다.
- 인증 과정
- 실제로 프론트엔드, 백엔드 개발 모두 인증 프로세스에 대해 이해하고 있으면 좋다.
- 그랩의 블로그 - 쉽게 알아보는 서버인증 시리즈
320x100
반응형
'Devlog > CS' 카테고리의 다른 글
| 객체 지향 프로그래밍이란? (0) | 2022.08.07 |
|---|---|
| 객체지향 5대 원칙 - SOLID 원칙 (0) | 2022.08.06 |
| 테스트 코드와 TDD 이해하기 (0) | 2022.07.11 |
| OSI 7계층과 TCP/IP 4계층 모델 (0) | 2022.06.22 |
| 프로그램 운영 기본 지식 (0) | 2022.06.21 |