웹 인증 방식

인증이 필요한 이유

• HTTP 프로토콜의 특징으로 인해 필요하다.
• 비연결성
  • 클라이언트가 서버에 요청을 하고나서 그에 걸맞는 응답을 보낸 후 서버와 클라이언트의 연결을 끊음
• 무상태성 (Stateless)
  • 연결이 끊긴 이후 서버가 어떠한 상태정보를 유지하지 않는 특성
    → 실제로는 데이터 유지를 하는 경우가 종종 있음

인증의 기본 동작 방식

• 인증 : 사용자가 누구인지 확인하는 절차 (ex. 로그인)

1. 클라이언트가 ID/PW 를 서버에 전송한다.
2. 서버는 ID/PW 를 기반으로 사용자 정보를 인증한다.
3. 인증된 사용자 정보를 기반으로 인증 정보를 생성한다.
4. 인증 정보를 클라이언트에게 전송한다.
5. 이후 요청에 대해서 클라이언트는 인증 정보를 활용하여 요청한다.

계정 정보를 요청 Header 에 넣는 방식

• 절대 이렇게 하면 안됩니다.
  보통 앱에서는 서버로 HTTP 요청을 할 때 따로 암호화 되지 않으므로, 해커가 HTTP 요청을 가로채서(intercept) 사용자의 계정정보를 알 수 있습니다.

Session / Cookie 방식

• Session/Cookie 방식 인증은 기본적으로 세션 저장소를 필요로 합니다.

1. 세션 저장소는 로그인시 사용자 정보를 저장하고, 열쇠로 사용할 수 있는 세션 ID 를 만듭니다.
2. 그리고 HTTP 헤더에 실어 클라이언트에게 보냅니다.
3. 브라우저는 세션 ID 를 포함하는 쿠키를 저장하고있습니다.
4. 인증이 필요한 요청에 해당 쿠키를 끼워 서버에 request 를 보냅니다.

인증 절차

1. 사용자가 로그인을 합니다.
2. 서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유 ID 값을 부여한 후 세션 저장소에 저장하고, 이와 연결되는 세션 ID 를 발행합니다.
3. 클라이언트는 서버에서 해당 세션 ID 를 받아 쿠키에 저장 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 끼워 보냅니다.
4. 서버에서는 쿠키를 받아 세션 저장소에서 확인 한 후, 일치하는 정보를 가져옵니다.
5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내줍니다.

Session 과 Cookie 의 차이점

• Session
  • 서버에서 가지고 있는 정보
• Cookie
  • 클라이언트에서 가지고 있는 정보
  • 서버에서 발급된 세션을 열기 위한 키 값 (세션 ID 라고 칭함)

Cookie 만 사용한 인증 처리

• 서버의 자원을 사용하지 않는 것 → 클라이언트가 인증 정보를 책임진다.
  → 클라이언트가 사용자 정보를 갖고있는다. → 보안에 취약할 수 있다.
• 쿠키만으로 인증을 할 경우, 해커가 HTTP 요청을 중간에서 뺏어갈 때, 모든 정보가 탈취됩니다.
• 또한, 쿠키에 담긴 정보는 쉽게 조작이 가능합니다.

Cookie 사용 예시

• 따라서 보안과는 관련 없는 장바구니, 자동로그인 설정 같은 경우에 유용하게 사용됩니다.

Session 과 Cookie 를 함께 인증 처리에 사용

• 인증의 책임을 서버가 지게 하기 위해서 세션을 함께 사용합니다. 
  클라이언트는 쿠키를 이용하고, 서버에서는 쿠키를 받아 세션의 정보를 접근하는 방식으로 인증을 합니다.

장단점

장점

• 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID) 는 유의미한 값을 갖고 있지 않습니다.
  → 중요한 정보는 서버 세션에 존재합니다.
• 사용자 고유의 ID 값을 발급받습니다. → 서버가 세션 ID를 사용하여 회원 정보를 검증할 때 유용합니다.

단점

• 세션 하이재킹 공격이 가능할 수 있다.
  → 해결책은 HTTPS 를 사용해 요청 자체를 탈취해도 안의 정보를 읽기 힘들게 하거나, 세션에 유효시간을 부여할 수 있습니다.
• 서버에서 세션을 저장하기 위한 추가 저장공간이 필요하다.
  → 서버에서 세션 저장소를 사용하므로 부하가 높아집니다.

Token 기반 인증 방식

• Token의 표준인 JWT는 인증에 필요한 정보들을 암호화 시킨 것 입니다.
  → JSON 형태로 된 토큰을 이용하는 방식 → 암호화 가능
• 위의 세션/쿠키 방식과 유사하게 사용자는 Access Token 을 HTTP 헤더에 실어 서버에 전송합니다.
• 토큰은 임의로 생성된 비밀번호 같이 동작합니다.
  → 제한된 수명을 가지고, 새로운 토큰은 한번 만료되면 새로 생성되어야합니다.(Refresh Token)

Cookie / Session 인증과의 차이점

• Cookie / Session 은 세션 저장소에 사용자 정보를 저장한다.
  Token 은 Token 안에 사용자의 정보를 넣는다. 대신 암호화를 수행한다.
• 서버에 별도의 저장공간이 필요하지 않다. → Token을 사용한 검증만 수행하기 때문
• 쿠키가 아닌 HTTP 헤더에 담아 서버에 전송한다. → 요청마다 명시적으로 추가해주어야 함.
• 서버가 상태를 유지하지 않아도 되므로 → App 환경에서도 사용이 가능하다.

JWT (JSON Web Token)

• JSON 형태로 된 토큰을 이용한 방식 → 사용자의 인증 정보를 텍스트 형태로 압축할 수 있음
  → 위 방법들의 문제점인 Scale 문제(DB에 사용자의 인증 정보를 저장 및 조회하며 생기는 과부하) 해결
• 구성
  
  • Header : Header, Payload, Verify Signature 를 암호화할 방식(alg), 타입(Type) 등을 포함합니다.
  • Payload : 서버에서 보낼 데이터 - 일반적으로 user의 id, 유효기간 포함
  • Verify Signature : Base64 방식으로 인코딩한 Header, Payload, Secret key 를 더한 후 서명됩니다.
  • Header, Payload 는 암호화 되지 않으므로, 디코딩하여 확인할 수 있습니다.
    → 그러므로 Payload 에 유저의 중요한 정보(비밀번호 등) 가 들어가면 쉽게 노출될 수 있습니다.
• 작동 과정
  

장단점

장점

• 간편하다.
  • Cookie / Session 인증은 별도의 저장소 관리가 필요합니다.
  • JWT 는 발급한 후 검증만 하기 때문에 추가 저장소가 필요하지 않습니다.
  • (StateLess - 상태/정보 저장하지 않음) 이는 서버를 확장하거나 유지, 보수하는데 유리합니다.
• 확장성이 뛰어나다.
  • 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능합니다.

단점

• 이미 발급된 JWT 에 대해서는 유효기간이 완료될 때 까지는 계속 사용이 가능합니다.
  • 세션/쿠키 인증 방식은 쿠키가 악의적으로 이용될 경우 쿠키를 삭제하면 됩니다.
  • 그러나 JWT 는 유효기간이 지나기 전까지 정보들을 이용할 수 있습니다.
    → 서버에서 토큰 상태를 저장하지 않기 때문에
    - 이에 대한 해결책은, Access Token 유효기간을 짧게 한다.
    Refresh Token을 활용하여 Access Token 을 갱신한다.
    그렇게 되면 Access Token 을 탈취당해도 상대적으로 피해를 줄일 수 있습니다.
• Payload 정보가 제한적이다.
  • Payload 는 따로 암호화되지 않기 때문에 디코딩하면 누구나 정보를 확인할 수 있습니다.
    → 따라서 유저의 중요한 정보들은 Payload 에 넣을 수 없습니다.
• JWT 의 길이
  • JWT 의 길이는 길기 때문에 인증이 필요한 요청이 많아질수록 서버의 자원낭비가 발생합니다.