session, token 기반 인증 ( OAuth )

wonkeunC·2022년 2월 23일
0
post-thumbnail

📝 세션 기반 인증 방식

이용자가 로그인이 되어있는 이용자만 페이지를 이용할 수 있는 상황을 가정할 때, 예전에는 로그인 상태 즉 내가 로그인을 했는지 안 했는지 끊임없이 확인하는 절차가 있었다.
서버의 세션(session)이라는 곳에 이용자의 로그인 정보가 저장되어 있다.

  • 쉽게 말해 서버의 메모리, 데이터베이스에 로그인 정보를 저장해둠.

1만 명이 가입된 유명한 사이트가 세션 기반 인증 방식을 사용한다고 가정할 때. 서버에는 회원들의 로그인 정보가 무수히 많이 쌓여 있을 것이다. 이렇게 되면 서버에 부하가 올 수 있다.
그렇기 때문에 예전에는 서버의 부하를 해결하기 위해 서버 A, 서버 B, 서버 C 이런 식으로 서버를 여러 개로 나뉘었는데 이렇게 되면 서버 관리가 복잡해진다.

왜 관리가 까다로울까?
B라는 서버는 300명이 이용할 수 있게 설정해 놨는데 300명 공간으로도 충분했던 B라는 서버로 관리했던 사이트가 인기가 폭발해서 이용자 수가 1000명으로 늘어났다고 가정하자.
그러면 B라는 서버는 1000명을 관리할 수 없어서 또 서버를 나눠야 한다. 이때 A 서버와 C 서버에 1000명의 데이터를 분배를 해야 하는데 어떻게 나눠야 할지 고민해야 한다.

심지어, B 서버에 지금 로그인한 사용자가 1000명이다. 하지만 B 서버에 2분 후에 500명이 추가로 로그인하여 1500명이 될 예정이고, 5분 후에 A라는 서버에 300명이 더 로그인하고 다른 서버에서도 이용자들이 들어오고 나갈 때 로그인 로그아웃이 빈번하게 일어나고 있을 때 골치가 아파진다. 어디에다가 누구를 넣을지.. CORS 문제도 일어나며 이런저런 문제가 많았다.

때문에,
최근에는 세션 인증 기반 방식 대신에 토큰 기반 인증 방식을 사용하게 되었다.


📝 토큰 기반 인증 방식

토큰 기반 인증 방식은 로그인 정보를 서버의 session에 담지 않은 것을 말한다.

그러면 내가 회원인 것을 어떻게 알 수 있을까?
접속하려는 사이트에 로그인 아이디와 패스워드를 입력했을 때 서버는 이 사람은 우리 회원이 맞다 아니다를 결정한다. 자신의 회원이 맞으면 회원이라는 것에 대한 인증 토큰을 준다.
그렇게 클라이언트에서 이 회원에 대한 토큰을 저장해놓고 회원이 게시글을 쓰거나 댓글을 쓸 때 서버에 토큰과 함께 요청을 보내는데 서버는 그 토큰을 보고서 자신의 회원이 맞군! 당신은 우리 사이트에서 특정 게시물을 써도 좋아요! 라는 응답을 한다.


🔍 OAuth2.0 그리고 JWT (Json Web Token)


OAuth의 동작 원리

OAuth : Open Authentication(인증), Open Authorization(권한) 인증과 허가를 포함

외부 서비스의 인증권한부여를 관리하는 프레임워크 즉, 토큰을 발급하고 인증하는 방법에 대한 프레임워크이다.

클라이언트하고 서버 사이에 인증을 하면 서버는 access_token을 클라이언트에게 준다.
그러면 클라이언트는 access_token을 가지고 API 요청을 할 수 있고. 서버는 클라이언트가 요청한 API 요청access_token 요청 두 가지를 받는다.
그러면 서버는 이 요청받은 두 가지를 가지고 이 클라이언트가 우리 사이트를 이용할 수 있는 권한이 있는지 없는지에 대한 여부를 판단하고 그 결과를 클라이언트에게 전달한다.

클라이언트와 서버만 놓고 봤을 때 토큰 기반 인증 방식과 똑같아서 간단해 보인다.
앞서 말했듯이 OAuth는 외부 서비스의 인증 및 권한부여를 관리한다.

🖇 OAuth는 플랫폼 간의 권한을 공유한다.

( OAuth는 인증과 권한을 둘다 관리한다 )

🍕 이용자가 우리 A 사이트를 이용하기 위해서 google 로그인을 하려는 상황일 때. 🍕

  1. 유저가 우리 A 사이트에 방문해서 로그인하려 한다.
  1. A 사이트는 google에 로그인 페이지를 요청함.
  1. A 사이트는 google에게서 로그인 페이지를 받음.
  1. A 사이트는 google에게서 받은 로그인 페이지를 유저에게 전달함.
  1. 유저는 google 로그인 페이지에서 자신의 아이디와 패스워드를 입력함.
  1. google은 유저의 로그인 회원가입 정보를 보고 자신의 회원이 맞는지 여부를 결정함
  1. google은 유저에게 자신들의 회원이 맞다는 것을 인증하는 권한 증서를 발급해 주는데 Authorization code라고 부르며 유저에게 준다.
  1. 유저는 google에게서 받아온 Authorization code 권한 증서를 A 사이트에게 전달한다.
  1. A 사이트는 유저에게서 받은 Authorization code 권한 증서를 가지고 google에게 가져간다.
  1. A 사이트는 Authorization code 권한 증서를 주는 대신 google에게서 access_token을 요청한다.
  1. google은 A 사이트에게 access_token을 준다.

(유저: client 가 A 사이트에 무언가를 요청할 때마다 A 사이트는 google에서 받은 access_token을 보고 유저를 계속 확인해야 한다. )

  1. A 사이트는 google에게서 받은 access_token을 유저에게 전달한다.
    (유저가 게시물을 보거나 쓰거나 할 때 access_token을 가지고 A 사이트에게 요청을 해야 해서)

이렇게 유저가 A 사이트에서 무언가를 하려 할 때 A 사이트는 유저의 access_token을 보고 응답 및 권한을 허가해 준다.


⚠️ 토큰은 만료가 되는 기간이 있다.

알아야 할 개념 !

  • Refresh_token은 정보를 포함한 access_token과 함께 발급을 받게 되며 access token보다 더 긴 유효기간을 가지게 된다.
  • Refresh_token은 access token의 유효기간을 보다 짧은 시간으로 설정하여 유효기간이 만료되었을 때 access token을 재발급 받을 수 있는 열쇠 역할을 하게 된다.

🍕 유저에게 주었던 access_token이 만료가 된 상태에서 A 사이트가 유저의 access_token을 받았을 때 ! 🍕

  1. A 사이트는 유저로부터 만료된 access_token을 받았을 때, A 사이트는 access_token과 함께 받았던 Refresh_token을 가지고 google에게 새로운 access_token을 요청한다.
  1. google은 새로운 access_token을 A 사이트에게 전달한다.
  1. A 사이트는 googe에게서 새로 받은 access_toke을 유저에게 전달한다.

이렇게 인증을 어떻게 진행하는지 알아보았다.
만약, access_token과 Refresh_token 둘다 만료가 되었을때는 유저에게 다시 로그인을 시키게한다.



🦀 Token이 왜 필요한지 개념 다시 짚고가기.

로그인은 사이트에 내가 누구인지를 알려주는 것이다.
내가 댓글을 달고 수정하고 게시글을 만들고 등 아무나 나의 게시글을 마음대로 할 수 있는 것이 아니라 내가 작성하고 수정한 게 맞는지를 알아야 하기 때문이다.
그렇기에 ID, PW를 통해 자신이 누구인지를 사이트에 알려줘야 한다.

하지만 이것 또한 악용될 소지가 있다. 즉, 다른 사람이 나 자신인 척할 수 있다는 것이다.
그 결과, 토큰(Token)과 인증(Authentication)이라는 것은 나날로 발전하게 된다.
발전한 Token으로 JWT (Json Web Token)이 있다



JWT (Json Web Token)

JWT : Json 형태로 이루어진 토큰의 한 형식이다. (보안에 조금 더 좋음)
누군가로 부터 탈취되어 변조가 되었는지를 확인할 수 있는 전자서명이 포함된 토큰(Token)이다.

JWT의 형태 : [header], [payload(내용)], [signature(서명)]

[header] : 토큰의 타입과 암호화 방식 정보가 들어간다.

[payload]: 토큰에 담을 정보가 name:value 쌍으로 들어간다.

[signature] : 서명 정보이다, secret key를 포함해서 [header][payload] 정보가 암호화 되어 들어간다.


🍕 JWT의 동작 방식 🍕
( 토큰 기반 동작 방식대로 움직인다. )

  1. 유저가 로그인을 시도한다.
  1. 서버가 요청을 확인 후 secret key를 가지고 access_token을 발급한다.
  1. 유저:client 에게 JWT를 전달한다.
  1. 유저:client는 API 요청을 할 때 Authorization header에 JWT를 담아서 보낸다.
  1. 서버는 JWT의 서명을 확인하고 payload에서 정보를 확인해서 API 응답을 보낸다.

🧹 정리하기

JWT와 OAuth는 로그인에 많이 쓰는 두 인증 방식이다.
JWT는 토큰(Token) 중에 하나이고 OAuth는 인증 권한 프레임워크이다.
그렇기 때문에 이 두 가지를 가지고 비교하는 것은 애매하다.

OAuth에서 토큰(token)으로 JWT를 사용할 수도 있다.
둘 다 토큰 기반 인증 방식으로 인증하는 것이기 때문에 너무 고민하는 것보다는 자신의 상황에 맞게 사용하는 것이 나을 것 같다.

profile
개발자로 일어서는 일기

0개의 댓글