[ C. S. ] 인증 방식 개념 정리

조만간 필요할 것 같기도 하고, 계속해서 다시 상기시켜야 할 주요 개념 중 하나인 인증 방식과 관련한 내용들을 정리해보려고 한다.

한창 면접때 공부했던 기억이 있는데 벌써 가물가물해진 것 같다.

애매하게 알고 있는 것은 정말 "내 것"이 아니다.

Cookies

• 쿠키를 이용해서 서버는 브라우저에 데이터를 넣을 수 있다.
• 사용자에 대한 내용을 기억하기 위함
• 어떤 사이트에 방문하면 브라우저는 서버에 요청을 보낸다.
• 서버는 이에 응답할텐데, 응답으로는 모든 데이터와 요청한 정보들이 있다.
• 응답에 추가로 브라우저에 저장하고자 하는 쿠키가 있을 수 있다.
• 사용자가 브라우저에 쿠키를 저장한 후, 해당 웹사이트를 방문할 때마다 쿠키와 함께 요청을 서버에 보내게 된다.
• 참고로 쿠키는 도메인에 따라 제한된다. 또한 쿠키는 유효기간(서버가 정한 기한에 따라)이 존재한다. (ex) 유투브가 준 쿠키는 유투브에만 전송되어짐
• 쿠키는 인증뿐만 아니라 다른 여러가지 정보들을 저장할 수 있다.
• 예를 들면, 웹사이트 언어설정을 바꾸면 서버는 이에대한 응답으로 쿠키를 주고, 브라우저는 요청에 대한 응답으로 언어값을 쿠키로 받아와서 저장한다.
• 따라서, 해당 웹사이트를 다음에 방문하게 될 때 쿠키(언어값)와 함께 서버로 전송되어지고, 서버는 해당 쿠키값에 대한 언어로 된 페이지를 제공.

 

HTTP 프로토콜

• HTTP 프로토콜은 웹사이트를 이용할 때 사용하는 프로토콜이다.
• 또한 stateless이다. 즉, 서버로 가는 모든 요청이 이전 요청과 완전히 독립적으로 다뤄진다는 의미이다. (요청끼리 연결이 없다. 메모리가 없다.)
• 그러므로 요청이 끝나게 되면 서버는 사용자가 누구인지 잊어버린다.
• 요청을 할 때마다 클라이언트가 누구인지 알려줘야 하는 방식으로 Sessions과 Token 방식이 존재한다.

 

Sessions

동작 순서

1. 로그인 하려는 유저가 본인의 ID, PW를 서버에 전송
2. 유효한 유저라면 서버는 세션 DB에 해당 유저에 대한 정보를 생성한다.
3. 저장함과 동시에 별도의 ID가 존재하여 이 세션 ID를 쿠키를 통해 브라우저에 저장된다.
4. 따라서, 같은 웹사이트의 다른 페이지로 이동하면 브라우저는 세션ID를 가지고있는 쿠키를 서버에게 전송한다.
5. 서버는 세션 ID와 함께 들어오는 쿠키를 확인한다. (여기까지 서버는 요청자가 누구인지 모른다.)
6. 서버는 세션 ID를 가지고 세션 DB를 확인하여 해당 유저가 누구인지 알아낸다.
7. 중요한것은 유저 정보는 모두 서버에 존재한다는 것! (유저가 가지고있는 것은 세션 ID값.)
8. 쿠키는 그저 세션 ID를 전달하기 위해 사용되어진다! 즉, 쿠키는 매개체이고 쿠키는 네이티브 앱에는 없고 브라우저에만 존재한다.

• 정리하면 세션은 모든 유저의 정보를 서버가 관리하고 있기 때문에 서버는 유저의 요청이 있을 때마다 쿠키를 받아서 세션 ID를 확인하고, 유저를 찾아내는 DB에 접근해야 한다!
• 그러므로 유저가 늘어난다면 DB 리소스가 필수적으로 더 필요하다.
• 세션을 위한 DB는 주로 Redis를 사용한다. (빠르고 저렴한 DB)
• 강제 로그아웃등과 같은 기능 구현이 가능.

 

Tokens

• 네이티브 앱에서는 쿠키를 사용할 수 없기 때문에 이 경우에는 토큰을 사용한다!
• 그냥 토큰은 이상하게 생긴 string 이다.

 

JWT

동작 순서

1. 로그인 하려는 유저가 본인의 ID, PW를 서버에 전송
2. 서버에서는 유저의 정보를 가지고, 사인 알고리즘을 이용해서 시그니쳐를 생성한다.
3. 이후 생성된 시그니쳐 정보를 string 형태로 사용자에게 전달한다.
4. 보통 JWT는 세션 ID보다 매우 길다. (길이에 대한 제약이 없음.)
5. 사용자가 요청을 보내면 세션 ID와 비슷하게 '사인된 정보(토큰)'을 서버에 보내야 한다.
6. 서버는 토큰을 받게되면 해당 사인이 유효한지(조작 여부) 체크하고 유저를 확인한다.

• 세션의 한계점을 극복하기 위해서 등장하게 되었다.
• 토큰 형식으로 JWT로 유저 인증을 처리한다면, 서버가 세션 DB를 가질 필요가 없다.
• 또한, 유저 인증을 위해 많은 작업을 할 필요가 없어지게 된다!
• 서버는 단지 토큰의 생성과 검증 작업만 할 뿐이다.
• 하지만 JWT는 암호화되지 않았다. 따라서 누구나 열어서 해당 컨텐츠를 볼 수 있다. (비밀정보를 JWT에 포함되면 X)
• 유저에 대한 정보들을 강력하게 관리하기 위해서는 JWT대신 세션을 활용하는게 낫다.