Session 기반 인증

• Session 을 기반으로 하는 인증방식을 설명하면

클라이언트

• 서버에 로그인 요청을 보내서 성공하면, 서버에서는 session을 발급해줍니다.
  • 이때 response http에 Set-Cookie 로 저장되어있습니다
• 발급받은 session 정보는 웹 브라우저(크롬이나 엣지같은)의 내부의 세션 저장소를 기반으로 사용자 정보를 저장하고 이후 요청시마다 서버에 인증 정보를 보냅니다

서버

• 각 사용자 Session 마다 고유한 SessionID 를 발급해줍니다. 이를 HTTP 헤더에 실어 클라이언트에게 보냅니다. (쿠키 발급 시 Set-Cookie 헤더에 의해 클라이언트에 쿠키값이 세팅됨)

통신의 흐름

• http Request 마다 서버에 의해 셋팅된 Set-Cookie 헤더 정보와 함께 보냄
• 서버에서는 Set-Cookie 와 함께 발급해놓고 저장한 SessionID 사용자를 인식하게 되며
• 클라이언트측의 웹브라우저는 Session 내부의 Cookie 라는 공간에 데이터를 저장해놓고 매 요청마다 쿠키를 보내고 받음

결론

• Session : 서버에서 가지고 있는 클라이언트의 정보, 고유한 SessionID 로 사용자를 식별
• Cookie : 클라이언트가 서버로부터 발급받은 고유한 식별 key (Session ID)
• 모든건 브라우저의 Session 공간, 그중에서 Cookie 를 기반으로 하므로 Web에서만 동작한다. App에서는 Session 자체가 없음

Token 기반

클라이언트

• 서버에 로그인 요청을 보내서 성공하면, 서버에서는 Access-Token을 발급해줍니다.
  • 이때 Access-Token은 그냥보면 의미를 알수 없도록 암호화해 발급해줍니다.
  • 일종의 입장권이며, 이 입장권은 암호화되어있어 서버에서만 해석&검증 할 수 있는 형태로 보내주는데, 많이 사용하는 토큰의 표준규격중 하나가 JWT이며, 암호화 알고리즘은 은 서버 마음대로 선택 가능합니다.
  • 근데 암호화 알고리즘이 이미 파훼법이 나와있는 쉬운 간단한 방법이라면 보안에 심각한 문제가 일어나게 됩니다. 마치 위조지폐를 누구나 손쉽게 집에서 만들수 있는 상황 되어버리기네요
  • 때문에 위조/해석이 어려운 암호화 방식을 사용 해야합니다. 지폐에 위조지폐를 식별할 수 있는 기술을 적용해놓으면 위조지폐를 만들더라도 이를 받은 사람이 위조되었음을 검증해낼수 있게요
• 이후 클라이언트는 매 요청마다 서버에게 발급받은 Access-Token을 HTTP-header 에 포함해 보냅니다.

서버

• 모든 http-request 마다 클라이언트로 부터 받은 Token 을 검증해(=복호화) 위조되지 않은 정상적인 Token 이라면 요청에 대한 정보를 클라이언트에게 제공해줍니다
• 서버가 클라이언트에게 발급해주는 Token 에는 조작여부를 판단하는 Verify Signature와 Secret key가 있고, 토큰의 유효기간 등이 담겨있습니다.
• Token 에 유효기간이 있는 이유는, 모든 암호화알고리즘이 "절대무적"을 보장하지 않기때문에, 충분한 컴퓨팅 리소스만 투입한다면(리소스 = 컴퓨팅파워*동작시간) 누구나 복호화가 가능하기 때문입니다. 일반적으로 10년정도 걸린다고 보면 됩니다
  • 10년 = (10년동안 지금기술로 열심히 풀거나 / 10년뒤 진보된 기술로 우아하게 뚫거나 / 남들보다 10년이상 기술이 앞서있는 NSA 같은데서 그냥 박살내버리거나 )
• 또한, 암호화가 어려우면 남들이 깨는것도 어려운데, 복호화또한 서버 리소스를 많이 사용하기 어려운 문제가 있습니다. 이를 해결하기 위해 Token 을 2단계로 분리하는데요
  • 강력한 암호화로 해킹하기도 어렵고 복호화도 어렵지만 오랜기간 나름 안전하게 오래록 사용할수 있어 유효기간을 길가 가져가면서 사용하는 토큰이며 일반적으로 refresh-token 이라고 부르는것
  • 가볍지만 빠른 암호화로 짧게 사용하며 일반적으로 Access-Token 이라고 부르는것