[Spring]인증과 인가

김세림·2024년 5월 22일

Spring

목록 보기
9/9
post-thumbnail

인증과 인가


인증과 인가

  • 인증(Authentication)
    • 인증은 해당 유저가 실제 유저인지 인증하는 개념
    • 여러분의 스마트폰에 지문인식, 이용하는 사이트에 로그인 등과 같이, 실제 그 유저가 맞는지를 확인하는 절차를 말한다.
  • 인가(Authorization)
    • 인가는 해당 유저가 특정 리소스에 접근이 가능한지 허가를 확인하는 개념이다.
    • 예를들어 관리자 페이지-관리자 권한 같은 것들을 들 수 있다.

두가지가 헷갈릴 수 있는데 쉽게말해 로그인 인증할때 비밀번호 입력하고 제출하는 그때는 인증이라고 보면되며, 회원/비회원의 여부에 따라 다른 권한을 받는 것이 인가라고 보면된다.

'웹 애플리케이션 인증'의 특수성


일반적으로 서버-클라이언트 구조로 되어있으며, 실제로 이 두가지의 요소는 아주 멀리 떨어져있다.
또한 Http 프로토콜을 이용하여 통신하는데 그 통신은 비연결성(Connectionless) 무상태(Stateless)로 이루어진다.

🔍잠깐! '여기서 비연결성과 무상태' 란?

비연결성(Connectionless)

서버와 클라이언트가 연결되어 있지 않다는 뜻이다.
채팅이나 게임 같은 것들을 하지 않는 이상 서버와 클라이언트는 실제로 연결되어 있지 않다.
그 이유는 리소스를 절약하기 위해서 인데, 만약 서버와 클라이언트가 실제로 계속 연결되어있다면 클라이언트는 그렇다고 쳐도, 서버의 비용이 기하급수적으로 늘어나기 때문이다.
그래서 서버는 실제로 하나의 요청에 하나의 응답을 내버리고 연결을 끊어버리고있다 라고 생각하면 될 것 같다.

무상태(Stateless)

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

그런데 우리가 사용할 때는 이전 정보들이 연결되서 나오는 것처럼 느껴졌는데..?

  • 그렇게 느껴지기 위해 개발자들이 노력을 했을 뿐...
    url을 계층적으로 설계하고 다음 요청에 대한 api url을 이전 계층에만 둔다면 연속적으로 사용하고 있다고 느낄 수 있게끔 만든다는 것!!

인증의 방식

쿠키-세션 방식의 인증


쿠키-세션 방식은 서버가 '특정 유저가 로그인 되었다'는 상태를 저장하는 방식이다.
인증과 관련된 아주 약간의 정보만 서버가 가지고 있게되고 유저의 이전상태는 전부는 아니더라도 인증과 관련된 최소한의 정보는 저장해서 로그인을 유지시킨다는 개념이다.

위 그림에 대해 약간 설명하자면
1. 사용자가 로그인 요청을 보내면
2. 서버는 DB와 대조해서 맞는지 확인을 하고
3. 일치한다면 인증을 통과한것으로보고 '세션 저장소'에 해당 유저가 로그인되었다는 정보를 넣는다.
4. 세션 저장소에서는 유저의 정보와는 아예 관련 없는 난수인 session-id를 발급하고
5. 서버는 로그인의 요청의 응답으로 해당 session-id를 내어준다.
6. 클라이언트는 그 session-id를 쿠키라는 저장소에 보관하고 앞으로의 요청마다 세션아이디를 같이 보낸다(주로 HTTP header에 담아서 보냄)
7. 클라이언트의 요청으로 쿠키를 발견했다면 서버는 세션저장소에서 쿠키를 검증한다.
8. 만약 세션저장소에서 유저정보를 받아왔다면, 이 사용자는 로그인이 되어있는 상태라는 것을 알수 있을 것이다.
9. 이후에는 로그인된 유저에 따른 응답을 내어주게된다.

JWT 기반 인증


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

이또한 위 그림에 대해 설명하자면
1. 사용자가 로그인요청을 보내면
2. 서버는 DB와 대조해서 맞는지 확인을 하고 (여기까지는 쿠키세션과 동일)
3. 일치한다면 인증을 통과한 것으로 보고 유저의 정보를 JWT로 암호화해서 내보낸다.
4. 서버는 로그인 요청의 응답으로 JWT 토큰을 내어준다.
5. 클라이언트는 그 토큰을 저장소에 보관하고 앞으로의 요청마다 토큰을 같이 보낸다.
6. 클라이언트의 요청에서 토큰을 발견했다면 서버는 토큰을 검증한다.
7. 이후에는 로그인 된 유저에 따른 응답을 내어준다.

조금 더 자세한 내용은 이후 포스트에서 따로 쿠키세션과 JWT를 다뤄보려고한다!

0개의 댓글