웹 인증

hellonayeon·2021년 11월 9일

인증이 필요한 이유

HTTP 프로토콜은 비연결(connectionless) 무상태(stateless) 특징을 가지므로 서버는 클라이언트의 이전 요청들을 기억하지 않으며, 이후에 오는 요청들을 각각 독립적으로 처리한다. 따라서 사용자 인증을 하고 난 이후에 다른 요청들을 보내더라도 서버는 해당 요청이 인증 된 사용자로부터 온 것인지 알 길이 없다. 이러한 HTTP 프로토콜의 특성을 보완하기위해 클라이언트는 매 요청마다 자신이 로그인을 수행했고 자원을 사용할 권리가 있는 사용자임을 서버측에 확인시켜줘야한다. 그래서 요청마다 사용자에 대한 인증이 추가적으로 필요하다.

인증 방식

웹 인증 방식을 검색해보면 Cookie와 Session을 비교하는 글이 많다. 처음에 나는 왜 이 둘을 비교해야 하는지 몰랐다. 서버 쪽에 사용자 인증 정보를 저장하는 Session 방식의 인증도 결국 클라이언트 쪽에서 자신이 누구인지 처음에 서버로부터 발급받은 SESSIONID를 저장하고 이후 요청마다 보내기 위해 Cookie를 사용하는데 말이다. 그래서 튜터님께 질문했는데 과거에는 Cookie만 사용하는 인증 방식을 사용했다고 한다🤭 사용자는 서버로 부터 만료일 이름 값 경로 정보가 담긴 데이터를 받아 브라우저의 Cookie 에 저장해놓고 이후 요청마다 요청 헤더에 Cookie 값을 삽입해서 보낸다.

Session

Session은 서버측에서 사용자와의 연결을 관리하는 방식이다. 사용자의 인증 절차를 거치면 서버측에서는 SESSIONID 값을 생성해서 사용자 정보와 매핑될 수 있도록 서버상의 메모리에 SESSIONID를 저장하고 관리한다. 생성한 SESSIONID를 사용자에게 보내면, 사용자는 SESSIONID를 Cookie에 저장해놓고 Cookie 인증 방식과 마찬가지로 요청과 함께 Cookie 값을 요청 헤더에 보낸다.

JWT

JWT는 암호화 토큰 기반 인증 방식이다. 서버는 사용자 정보를 기반으로 JSON 형식의 데이터를 생성하고 이를 암호화해서 사용자 측에 전달한다. 전달받은 내용은 브라우저의 Local Storage에 저장하고 사용자 인증이 필요함에 따라 요청 헤더의 Authorization 값에 넣어서 전달할 수 있다.

OAuth

OAuth는 사용자 인증을 다른 서비스로 위임하도록 하는 프로토콜이다. 자체 서비스에서 직접 사용자 인증 과정을 거치지 않고 다른 웹 서비스에 등록된 사용자 정보를 사용하는 방식이다. 앞서 정리했던 Cookie Session JWT 방식에서는 사용자가 서버쪽으로 인증을 요청했지만, 이와 다르게 인증을 요청하는 주체는 우리의 애플리케이션 서버가 된다. 사용자가 인증 요청을 보내면 서버는 이를 우리의 웹 애플리케이션 서버가 아닌 다른 인증 서버인 제 3의 웹 서버인 Authorization Sever로 전달해서 인가를 확인받고 Access Token을 발급 받는다. 이후 우리의 애플리케이션에서 사용하고 싶은 사용자 정보와 관련된 자원을 가지고 있는 서버인 Resource Sever로 Access Token을 보내어 인증 후 자원을 획득하게 된다.

정리

📝 용어 정리

Authentication
사용자의 신원을 확인하는 행위
Authorization
사용자의 권한을 확인하는 행위
Cookie
브라우저 저장소
Session
클라이언트와 서버의 연결 단위
|__ 일정 시간동안 같은 클라이언트로 부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술
JWT
웹 사용자 인증을 위한 암호화된 JSON 형식의 토큰
OAuth
사용자 인증을 다른 서비스로 위임하기 위한 프로토콜