인증(Authentication):

• 정의: 인증은 사용자 또는 시스템이 자신을 주장하는 실체(사용자, 서비스, 애플리케이션)의 신원을 확인하는 프로세스

• 목적: 사용자 또는 시스템이 자신이 주장하는 신원을 입증하여 시스템에 접근할 권한이 있는지 확인

• 예시: 사용자 이름과 암호를 입력하여 로그인하는 것이 인증의 한 예이다. 또는 생체 인식(지문, 얼굴 인식)을 사용한 인증도 있다.

인가(Authorization):

• 정의: 인가는 인증된 사용자 또는 시스템에게 특정 자원 또는 서비스에 대한 액세스 권한을 부여하는 프로세스

• 목적: 인증된 엔터티가 특정 자원에 액세스할 수 있는지 결정하고, 어떤 동작(읽기, 쓰기, 삭제 등)을 수행할 수 있는지 규정한다.

• 예시: 파일 시스템에서 특정 파일에 대한 읽기 또는 쓰기 권한을 부여하는 것이 인가의 한 예이다. 또한 웹 애플리케이션에서 특정 페이지에 대한 역할 기반의 액세스 제어도 인가의 예시이다.

쇼핑몰 웹페이지를 예시로 들자면, 로그인 하는 과정이 인증이고, 고객 계정, 관리자 계정이 따로 있어 상품을 등록할 수 있는 계정이 따로 있는 즉, 기능 접근 가능 여부를 판단하는 과정이 인가이다.

인증 방법

인가는 백엔드 측에서 계정별로 접근할 수 있는 기능을 제한하면 되고, 인증 개념에는 크게 두가지 방법이 있는데 바로 세션과 와 토큰이다. 이 둘에 대해서 먼저 알아보자.

Cookie 개념

<정의>

• <key , value> 형태의 문자열로 브라우저에 저장되어 사용자를 인식하거나 일부 데이터를 저장하는 역할을 수행한다.

• 서버가 클라이언트에 정보를 전달할 때 저장하고자 하는 정보를 응답 헤더(Cookie)에 저장하여 전달한다.

<필요성>

• 서버에 요청할 때 마다 사용자가 ID, PW를 통해 로그인을 해야하는 불편함이 있었기 때문이다.

• Cookie는 사용자가 한번 로그인을 하면, 쿠키를 생성하여 저장하고 이후 요청은 로그인없이 진행할 수 있는 편의성을 제공해준다.

<문제점>

• Cookie가 노출되었을 때 ID, PW와 같은 중요정보들이 쉽게 노출된다.

• 웹 브라우저마다 Cookie에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능하다.

• Cookie의 사이즈는 4KB로 제한되어 많은 양의 데이터를 담을 수 없다.

<종류>

• 세션쿠키(Session Cookie) :

  아래에 후술 할 세션이라는 작업단위 동안만 저장되는 쿠키이다. 보통 세션ID와 같은 세션에 대한 정보와 로그인 정보 및 장바구니와 같은 일시적 데이터를 저장한다.

• 지속쿠키(Persistence Cookie)

  따로 설정 시 웹브라우저가 꺼지는 세션 이후에도 유지가능하다. 보통 웹페이지를 껐다 켜도 로그인 상태를 유지하기 위한 작업 같은 곳에 쓰인다.

세션쿠키와 지속쿠키는 파기시점 외에 차이점이 없다. Discard라는 파라미터가 설정되어 있거나, 파기까지 남은시간인 Expires또는 Max-Age라는 파라미터가 없으면 세션쿠키이다.

보통 Cookie 는 text 형태로 저장되어 백엔드 작업 시 String으로 부여하는 듯하다. ← 나중에 확인필요

쿠키에 대한 데이터는 서버가 클라이언트에게 보내는 http response 의 header 부분에 담겨져 보내진다.

Session 개념

세션이란 일정 시간동안 같은 사용자(정확하게 브라우저를 말한다)로 부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술이다.

또한 여기서 일정 시간이란 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점으로부터 웹 브라우저를 종료함으로써 연결을 끝내는 시점을 말한다.

즉, 방문자가 웹서버에 접속해 있는 상태를 하나의 단위로 보고 세션이라고 칭한다는 것이다.

또한, 관련 데이터를 저장한다는 개념도 있는데, 클라이언트(웹 브라우저 - 로컬)에 저장되는 쿠키와 다르게 서버쪽에 암호화 되어 저장되기에 안정성이 상대적으로 높으며, 세션쿠키와 같이 세션이 끝나면 해당 세션의 데이터도 자동으로 삭제 된다. 그렇기에 유지 필요한 데이터의 경우 따라 DB에 옮겨 저장해둬야한다.

세션은 일정시간 동안 유지되는 일의 단위(정보) 와 해당 정보를 저장하는 저장소의 개념을 겸하는 단어이다. 이를 위해 쿠키를 이용하기도 한다.(세션ID - 세션쿠키에 저장)

그래서 쿠키(Cookie)와 세션(Session) 적어도 사용자 정보처리 내용에 대해서는 보통 묶어서 취급한다. 사이트 이용자에 대한 기록을 임시로 저장하기 위해 이용되는 것들이며, 보통 노출되면 안되는 정보는 세션에 상관없는 정보는 쿠키에 저장한다. 세션에 과도하게 많은 정보를 저장시 서버에 무리가 가고, 쿠키는 저장할 수 있는 데이터 한계가 있으니 적절히 선택하여 운영해야한다.

쿠키와 세션을 사용하는 이유

• HTTP가 비연결성(connectionless)와 상태정보 유지안함(stateless)의 특징을 갖기 때문이다.

• 웹 서비스를 이용하면서 유지해야될 로그인 정보와 매번 연결 시 불러와야 하는 이미지 파일과 같은 정보를 저장하여 좀 더 간편하고 빠르게 서비스를 이용하기 위함

쇼핑몰을 예시로 하면. 로그인 하지 않은 상태에서 장바구니에 물건을 담거나 이전에 입력한 검색어를 찾는 등의 작업에는 쿠키가 쓰이는 것이다. 해당 데이터들은 남들이 봐도 딱히 상관없는 것들이기 떄문이다. 요청시 마다 서버가 누구의 요청인 줄 알아야하기에 무의미한 반복을 막기 위해 세션을 이용하고, 해당 세션의 ID(승인된 세션이라는 증거)는 쿠키에 저장하여 요청마다 ID를 보내어 서버의 DB에 있는 ID와 대조하여 확인

Cache 개념

캐시는 임시 창고라고 생각하면 된다. 웹사이트에서 동영상, 영상과 같은 부피가 꽤 되는 데이터들을 그때그때마다 주고 받으면 네트워크도 서버도 버티지 못한다. 그래서 가장 많이 쓰는 방식이 브라우저 캐시로서 웹서핑 시 브라우저 캐시에 저장해 두고 쓴다.

캐시는 하드웨어적으로도 쓰는 단어이다. 용도는 같다.

• 캐시는 이미지, 비디오, 오디오, css, js파일 등 데이터나 값을 미리 복사해 놓는 리소스 파일들의 임시 저장소이다.

• 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공한다.

• 같은 웹 페이지에 접속할 때 사용자의 PC에서 로드하므로 서버를 거치지 않아도 된다.

• 이전에 사용된 데이터가 다시 사용될 가능성이 많으면 캐시 서버에 있는 데이터를 사용한다.

• 그래서 다시 사용될 확률이 있는 데이터들이 빠르게 접근할 수 있어진다. (페이지의 로딩 속도 ↑)

• 캐시 히트(hit) : 캐시를 사용할 수 있는 경우 (ex. 이전에 왔던 요청이랑 같은 게 왔을 때)

• 캐시 미스(miss) : 캐시를 사용할 수 없는 경우 (ex. 웹서버로 처음 요청했을 때)

✅쿠키와 캐시의 차이

쿠키와 캐시 모두 정보를 저장하여 재활용하는 기술이지만, 쿠키는 사용자의 수고를 덜어주는 데 목적을 두고 캐시는 데이터의 전송량을 줄이고 서비스 이용 속도를 높이는 데 목적을 둡니다.

캐시는 웹 페이지를 빠르게 렌더링 할 수 있도록 도와주고,

쿠키/세션은 사용자의 인증을 도와준다.

위의 그림이 앞서 말한 3가지 요소의 보편적인 저장 위치와 상호 작용에 대한 그림이다.

Token 개념

위의 3요소로 많은 것을 해결할 수 있었으나, 완벽하진 않았다. 세션의 처리과정을 보면, 클라이언트가 요청을 보내면 http request의 header에 (세션)쿠키에 저장되어 있던 세션ID를 넣어 서버에 넘긴디. 그러면 서버가 해당 세션ID가 서버쪽 DB에 들어있는지 확인을 하고, 대상이 있으면 요청을 처리한다. 즉, 요청 시마다 DB에서 해당 ID가 있는지 확인해야 되는 작업이 필요한 것인데, 이러면 서버쪽에 부담이 많이 가게 된다. 이에 대한 대안 중 하나가 바로 Token 방식이다.

토큰은 이전에 정리한 비대칭키의 개념을 이용하는 방식이다.

위는 가장 대표적인 토큰 방식은 JWT(Jason Web Token) 방식의 구조이며, 이에 대한 정리는 후에 따로 하겠다.

기본적으로 쿠키, 세션 과 토큰을 분리하여 생각하면 된다.

토큰은 서버가 개인키 하나만 노출시키지 않고 가지고 있으면 되기에 쿠키, 세션 처럼 DB를 뒤져가면 찾을 필요가 없어 서버에 대한 부하가 많이 줄어든다. 단, 토큰 자체의 데이터가 강대적으로 커 서버 대신 네트워크에 무리가 갈 수 있다.

토큰은 서버에 부담이 덜가는 대신에 네트워크에 부담이 간다.

Token 방식의 단점

1. 쿠키/세션과 다르게 토큰 자체의 데이터 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해질수 있다.

2. Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다.

3. 토큰을 탈취당하면 대처하기 어렵다. (따라서 사용 기간 제한을 설정하는 식으로 극복한다)