next-auth 이용하기(2)-로그인 방식을 이해해보자
📌시작하며
이전 포스팅에서 OAuth에 대해서 정리해보았고, 이번엔 다른 로그인 방식에 대해서 정리해보고자 한다. 전에 면접 후기를 보았을 때 ‘세션 로그인 방식과 토큰 로그인 방식의 차이를 아시나요?’ 라고 물으셨다고 하는데, 나 또한 그 질문을 들었다면 🥹(…네?) 하고 당황할 것 같기 때문이다. 그리고 이왕 로그인 방식에 대해 알아보기 시작했으니 이번 기회에 잘 비교해서 정리해두면 다른 로그인 방식을 이해할 때도 분명 도움이 되리라 생각한다.
✅Session
먼저, Session이 무엇일까?
나는 세션하면 쿠키와 비교되는 글을 자주 보곤 했다.(아마 개발자 분들은 스택오버플로우에 들어갈 때 쿠키를 허용해달라는 팝업을 자주 보았을 거다…) 쿠키가 사용자 브라우저 측에 저장되는 데이터 저장소라면, 세션은 사용자가 애플리케이션에 접속했을 때 서버측에 생기는 저장소라고 할 수 있다. 이렇게 생성 된 세션에 (세션 방식의 로그인의 경우) 사용자 인증정보도 함께 저장되는 것이다.
➡️Session 로그인 방식
사용자(브라우저)가 서버에 요청을 보낸다. 이 요청에는 사용자의 자격 증명과 요청하는 정보가 포함된다.
웹 서버는가 사용자를 인증한 다음, 세션을 생성하고 세션에 관한 정보를 DB에 저장한 후 사용자에게 세션 ID(세션 식별자)를 반환한다.
이 세션 ID는 브라우저 쿠키에 저장되어, 사용자가 요청을 시도할 때 쿠키에 이 내용을 담아, 서버에 요청하게 된다.
웹 서버는 전달 받은 세션 ID를 확인하고 해당 세션에 대한 정보가 있는지 확인한다.
세션 ID가 유효한 경우, 웹 서버는 사용자를 인증하고 요청된 정보를 반환한다.
✅Token
토큰은 OAuth의 access Token으로 살펴본만큼 반가운 이름이다. 토큰인 인증을 위해 사용되는 데이터라고 할 수 있다. 이 토큰은 암호화 할 수 있고, 서버에서 생성 되어 클라이언트 측에 저장된다. 따라서, 사용자가 서버에 새로운 요청을 보내야 할때 이 토큰을 함께 전송하게 된다.
➡️Token 로그인 방식
- 클라이언트가 자격 증명과 함께 서버에 요청을 보낸다.
- 애플리케이션(서버)이 자격 증명을 확인하고 토큰을 생성한다.
- 토큰은 클라이언트로 전송되어 클라이언트 측에 저장된다.
- 클라이언트가 서버에서 새로운 요청을 할 때, HTTP 헤더를 통해 토큰을 함께 보낸다.
- 서버는 첨부된 토큰을 디코딩하고 확인한다. 해당 토큰이 유효한 경우, 서버는 클라이언트에 응답을 보낸다.
- 클라이언트가 로그아웃하면 토큰은 파괴된다.
✅JWT
JWT는 Json Web Token의 약어로, JSON 객체로 정보를 안전하게 전송하기 위한 방법을 정의하는 개방형 표준(RFC 7519)이다. JWT는 헤더(Header), 페이로드(Payload), 서명(Signature) 세부분으로 구성된다.
| Header | JWT의 유형과 암호화 방법 |
|---|---|
| Payload | 토큰에 담길 정보 |
| Signature | Header와 Payload를 암호화한 값 |
✅OAuth와 Token 인증 방식의 차이점
Token 인증 방식도 알아보았지만, 여기서 혼란이 발생한다. 분명 OAuth도 Token을 사용했는데 Token 기반 방식이랑 동일한 건지, 아니면 다른건지. 그래서 이 부분을 추가적으로 정리해보면,
OAuth는 인증 및 권한 부여를 위한 프로토콜이며, Token 인증은 클라이언트에게 발급된 토큰을 사용하여 인증을 처리하는 것이다.
📩마무리
개발 공부를 하면서 새로운 것을 알아가는 것이 즐겁지만, 어렸을 때 부터 사용하던 로그인이란 기능에 이러한 다양한 과정을 통해 이루어진다는 걸 알 수 있어서 정말 흥미로웠다.😎