인증을 하는 이유

• 프론트엔드의 관점에서 인증은 사용자의 로그인, 회원가입과 같이 사용자의 도입부분을 말합니다. 백엔드(서버)에서는 모든 API요청에 대해 사용자를 확인하는 작업입니다.
  사용자 A와 B가 서비스(앱)를 쓸 때 두 사용자는 정보 및 보유하고 있는 컨텐츠들이 다를 것입니다. 그래서 서버에서는 A,B가 요청을 보냈을 때 누구의 요청인지 알아야 합니다. 만약 서로의 정보가 뒤바뀐다면 정보가 유출되는 상황이 올 수 있기 때문에 앱에서는 사용자가 누구인지 알 수 있는 정보를 서버에 보내고 서버는 이 정보를 바탕으로 각 요청에 맞는 데이터를 줘야합니다.

HTTP Protocol

• 현재 웹, 앱에서 가장 많이 쓰이는 방식은 HTTP 통신방식이다. HTTP 통신은 응답 후 연결을 끊으며 이전 정보를 담지 않는다. 즉 지김 보낸 HTTP요청은 과거에 내 정보를 담아 보낸 http요청과는 관계가 없으므로 인증을 위해서는 각각의 요청에 대해 보내는 사용자가 누구인지에 대한 정보가 필수적입니다.
  서버에 요청을 보내는 작업은 HTTP 메세지를 보내는 것입니다. 보통 헤더와 바디로 구성되며 헤더에 요청의 정보가 들어가고 바디에는 보낼 데이터가 들어가게 됩니다. 보통 앱/웹 서비스의 인증은 HTTP 메세지의 헤더에 인증 수단을 넣어 요청을 보내게 됩니다.

인증 방식

1. Session / Cookie 방식

Session/Cookie 방식 순서

• 사용자가 로그인을 한다
• 서버에서는 계정정보를 읽어 사용자를 확인한 후, 사용자의 고유한 ID값을 부여하여 세션 저장소에 저장한 후 이와 연결되는 세션ID를 발행합니다.
• 사용자는 서버에서 해당 세션ID를 받아 쿠키에 저장을 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냅니다.
• 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져옵니다.
• 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내줍니다.

Session/Cookie 방식의 인증은 세션 저장소를 필요로 합니다(Redis(빠른 오픈소스 인 메모리 키값 데이터 구조 스토어)를 많이 사용함). 세션 저장소는 로그인을 했을 때 사용자의 정보를 저장하고 열쇠가 되는 세션ID값을 만듭니다. 그리고 HTTP 헤더에 넣어 사용자에게 보냅니다. 그러면 사용자는 쿠키로 보관하고 있다가 인증이 필요한 요청에 쿠키(세션ID)를 넣어 보냅니다.

*장점

• Session/Cookie 방식은 기본적으로 쿠키를 매개로 인증을 거칩니다. 여기서 쿠키는 세션 저장소에 담긴 유저 정보를 얻기 위한 열쇠입니다. 따라서 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 중요한 정보는 서버 세션에서 가지고 있기 때문에 쿠키 자체(세션ID)는 유의미한 값을 가지고 있지 않습니다. 즉, 쿠키에 담긴 HTTP 요청이 노출되더라도 쿠키 자체(세션ID)는 유의미한 값을 가지고 있지 않기때문에 안전합니다.
• 일일이 사용자정보를 확인할 필요가 없이 바로 어떤 사용자인지를 알 수 있어서 서버의 자원에 접근하기 용이합니다.

*단점

• 쿠키(세션ID) 자체는 안전하지만, 만약 HTTP 요청을 다른 사람이 해킹할 경우 그 안의 쿠키를 가로채서 HTTP 요청을 보낼 수 있습니다.
• 서버에서 세션 저장소를 사용하기 때문에 추가적인 저장공간을 필요로 하게 되고 자연스레 부하도 높아질 것입니다.

2. JWT 방식

인증에 필요한 정보들을 암호화 시킨 토큰을 말한다. Access Token을 HTTP 헤더에 실어 서버로 보냅니다.

JWT 구성요소 ( Header, Payload, Verify Signature)

• Header : 위 3가지 정보를 암호화할 방식(alg), 타입(type) 등이 들어갑니다.(agl : HS256, type: jwt)
• payload: 서버에 보내질 데이터입니다. 유저 아이디, 유효기간 등이 들어갑니다.
• Verify Signature: Base64로 인코딩한 Header와 Payload, SECRET KEY

장점

• 간편합니다. 세션/쿠키는 별도의 저장소의 관리가 필요하지만 JWT는 발급한 후 검증만 하면 되기 때문에 추가적인 저장소가 필요 없습니다. 즉 상태를 저장하지 않는 서버를 만드는데 용이하고 서버를 확장하거나 유지, 보수하는데 유리합니다.
• 확장성이 뛰어납니다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능합니다. 예를 들어 Facebook, Google의 경우 모두 토큰기반의 로그인이기 때문에 선택적으로 이름이나 이메일 등을 받을 수 있는 권한도 받을 수 있습니다.

단점

• 이미 발급된 JWT는 돌이킬 수 없습니다. 세션/쿠키의 경우 악의적으로 이용되면 세션을 지워버리면 되지만, JWT는 한번 발급되면 유효기간 완료전에는 사용이 가능합니다. 그래서 유효기간 내에는 정보 탈취가 가능합니다.
• Payload 정보가 제한적입니다. Payload는 따로 암호화 되지 않기 때문에 디코딩만 하게 되면 누구나 정보를 확인할 수 있습니다. 따라서 중요한 정보(개인정보 등)들은 Payload에 넣을 수 없습니다.