인증(Authentication)
인가(Authorization)

인증

해당 유저가 실제 유저인지 인증하는 개념이다.
지문인식, 사이트 로그인 등 유저가 입력한 정보를 토대로 실제 그 유저가 맞는지를 확인하는 절차이다.

인가

해당 유저가 특정 리소스에 접근이 가능한지 허가를 확인하는 개념이다. 관리자 페이지 접근과 같이 해당 유저의 권한등급을 확인하는 것이다.

웹 애플리케이션 인증

일반적으로 서버<->클라이언트 구조로 되어있고 이 둘은 대부분 물리적으로 가까이 있지 않다. 그리고 HTTP라는 프로토콜을 이용하여 통신하는데 그 통신은 비연결성 무상태로 이루어져있다.

비연결성

서버와 클라이언트가 연결되어있지 않다는 것이다.
예를 들어 스마트폰과 usb를 통해 연결된 컴퓨터는 스마트폰의 허가 없이 내부 정보를 가져올 수 있다. 그러나 우리는 웹 사이트를 배포하는 서버와는 연결되어있지 않다. 그저 인터넷으로 그 사이트를 보여달라고 서버에 요청해서 반환되어오는 정보로 사이트를 브라우저에 그릴 뿐이다.
단, 채팅이나 게임등 서버와 실시간으로 통신해야 하는 경우는 연결되어있다고 할 수 있다.
이렇게 특수한 경우에만 연결되어있는 이유는 리소스를 절약하기 위해서이다. 서버와 클라이언트가 실제로 계속 연결되어있다면 서버의 비용이 기하급수적으로 늘어나기 때문이다. 그래서 서버는 하나의 요청에 하나의 응답을 주고 연결을 끊어버린다.

무상태

서버가 클라이언트의 상태를 저장하지 않는다는 것이다. 기존의 상태를 저장하는 것들도 마찬가지로 서버의 비용과 부담을 증가시키는 것이기 때문에 기존의 상태가 없다고 ㅏ정하는 프로토콜을 이용해 구현되어있다.
실제로 서버는 클라이언트가 직전에, 혹은 그 전에 어떠한 요청을 보냈는지 전혀 알지 못한다.(로그를 남기는 것은 관리자가 보기 위함이지 서버 자체는 해당 정보를 저장하지 않는다)

의문점

그러나 우리는 웹 사이트를 이용할 때 로그인을 하면 브라우저를 끌 때까지 혹은 껐다 켰는대도 로그인이 유지 되는 경우가 있다. 로그인도 유지되고 페이지를 여기저기 넘어 다녀도 내 권한이 유지되는 모습을 볼 수 있었다. 왜 그런 것일까?

그렇게 보이게 하기 위한 개발자들의 노력이라 할 수 있다. 예를 들어 네이버 뉴스의 경우 url을 /article/015
와 같이 계층적으로 설계하고, 다음 요청에 대한 api url을 이전 계층에만 둔다면 연속적으로 사용하고 있다고 느낄 수 있다.

인증의 방식

쿠키-세션 방식

쿠키-세션 방식은 서버가 유저의 상태를 저장하는 방식이다.
해당 유저의 인증과 관련된 아주 약간의 정보를 서버가 가지고 있어 그 것을 확인하는 식으로 로그인을 유지하는 개념이다.

아래는 그림의 각 번호에 해당하는 설명이다.

1. 사용자가 로그인 요청을 보낸다.
2. 서버는 DB의 유저 테이블을 뒤져서 아이디 비밀번호를 대조해본다.
3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고 “세션 저장소”에 해당 유저가 로그인 되었다는 정보를 넣는다.
4. 세션 저장소에서는 유저의 정보와는 관련 없는 난수인 session-id를 발급한다.
5. 서버는 로그인 요청의 응답으로 session-id를 반환한다.
6. 클라이언트는 그 session-id를 쿠키라는 저장소에 보관하고 앞으로의 요청마다 session-id를 같이 보낸다. (주로 HTTP header에 담아서 보낸다)
7. 클라이언트의 요청에서 쿠키를 발견했다면 서버는 세션 저장소에서 쿠키를 검증한다.
8. 만약 유저정보를 받아왔다면 이 사용자는 로그인이 되어있다는 것을 알 수 있다.
9. 이후에는 로그인 된 유저에 따른 응답을 내어준다.
10. 로그인 이후 요청은 6~9번을 반복한다.

JWT 기반 인증

JWT란 JSON Web Token이라고 한다. 인증에 필요한 정보들을 암호화시킨 토큰을 의미한다. JWT기반 인증은 쿠키-세션 방식과 유사하게 JWT 토큰(Access Token)을 HTTP header에 실어서 서버가 클라이언트를 식별한다.

아래는 그림의 각 번호에 해당하는 설명이다.

1. 사용자가 로그인 요청을 보낸다.
2. 서버는 DB의 유저 테이블을 뒤져서 아이디 비밀번호를 대조해본다.
3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고 유저의 정보를 JWT로 암호화 해서 내보낸다.
4. 서버는 로그인 요청의 응답으로 JWT 토큰을 내어준다.
5. 클라이언트는 그 토큰을 저장소에 보관하고 앞으로의 요청마다 토큰을 같이 보냅니다.
6. 클라이언트의 요청에서 토큰을 발견했다면 서버는 토큰을 검증과정을 거친다.
7. 이후에는 로그인 된 유저에 따른 응답을 내어준다.
8. 로그인 이후 요청은 5~7번을 반복한다.