Cookie, Session, JWT(Json Web Token) pt.2

11. JWT의 구조와 각 부분(header, payload, signature)의 역할에 대해 설명해주세요.

JWT(Json Web Token)은 세 부분으로 이루어져 있습니다: Header, Payload, 그리고 Signature.

Header: Header는 토큰의 타입과 사용된 암호화 알고리즘을 명시합니다. 일반적으로 JWT는 HMAC 알고리즘 혹은 RSA를 사용합니다. 예를 들어, Header는 다음과 같이 구성될 수 있습니다.

{ "alg": "HS256", "typ": "JWT" }

여기서 "alg"는 암호화 알고리즘을, "typ"는 토큰의 타입을 나타냅니다.

Payload: Payload 부분은 'Claim'이라고도 불리며, 토큰 자체에 포함될 실제 정보를 담고 있습니다. 이 정보는 이름(name), 만료 시간(exp), 주제(subject) 등 다양한 형태가 될 수 있습니다.

{ "sub": "1234567890", "name": "John Doe", "admin": true }

여기서 "sub"는 주제를, "name"은 이름을, "admin"은 관리자 권한 여부를 나타냅니다.

Signature: Signature는 Header와 Payload를 이용하여 생성되며, 이들이 변조되지 않았음을 확인하는데 사용됩니다. Header와 Payload를 각각 Base64로 인코딩한 뒤, Secret Key와 함께 지정된 암호화 알고리즘을 통해 해시를 생성합니다.

예를 들면, HMAC SHA256 알고리즘을 사용한다면, 다음과 같이 Signature를 생성할 수 있습니다.

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

이렇게 생성된 JWT는 각 부분을 점(.)으로 연결하여 사용합니다: encodedHeader.encodedPayload.encodedSignature. 이 형태의 문자열이 HTTP 요청의 Authorization 헤더에 "Bearer" 토큰으로 담겨 서버에 전송되며, 서버에서는 이를 검증하여 요청의 유효성을 판단합니다.

 

12. JWT는 어떻게 암호화되나요? 그리고 암호화된 JWT는 어떻게 복호화되나요?

JWT (JSON Web Token)는 두 가지 방법으로 보호할 수 있습니다: 서명 및 암호화.

1. 서명(Signing): JWT의 가장 일반적인 보호 방식은 서명입니다. 서명은 JWT의 무결성을 보장합니다, 즉 토큰이 전송되는 동안 조작되지 않았음을 입증합니다. 서명은 토큰의 Header와 Payload를 각각 Base64Url 인코딩하고, 그 두 값을 연결한 후 ("header.payload") 시크릿 키와 함께 해시 알고리즘을 적용하여 생성합니다. 이렇게 생성된 서명은 토큰의 세 번째 부분을 형성합니다. 받는 측은 동일한 프로세스를 사용하여 서명을 검증할 수 있습니다: 동일한 헤더, 페이로드, 시크릿을 사용하여 새로운 서명을 생성하고, 이것이 받은 토큰의 서명과 일치하는지 확인합니다.
2. 암호화(Encryption): JWT는 또한 기밀성을 보장하기 위해 암호화될 수 있습니다. 이는 토큰의 내용을 숨기는 데 사용되며, 이렇게 암호화된 토큰은 JWT를 받아들이는 측만 복호화하고 읽을 수 있습니다. JWT를 암호화하는 것은 상당히 복잡한 과정이며, 여러 가지 방식이 있습니다(JWE - JSON Web Encryption을 참조하세요).

이미 서명된 JWT는 다시 암호화될 수도 있습니다. 이러한 방식은 "nested JWT"라고 부르며, 먼저 JWT를 서명하고 그 결과를 암호화하여 결과적으로 무결성과 기밀성을 모두 보장하는 토큰을 생성합니다.

기억해야 할 중요한 점은, JWT 서명은 토큰의 무결성을 보장하지만 내용을 숨기지는 않는다는 것입니다. JWT 페이로드는 Base64로 인코딩되므로, 중요한 개인 정보가 포함된 경우 반드시 암호화를 적용해야 합니다.

 

13. JWT의 Secret Key가 유출되면 어떤 문제가 발생하나요? 이 문제를 어떻게 해결하나요?

JWT의 Secret Key는 토큰의 무결성을 보장하는 역할을 하기 때문에, 이 키가 유출되면 매우 심각한 보안 문제가 발생할 수 있습니다.

1. 문제: Secret Key가 유출되면 공격자는 해당 Key를 사용하여 JWT를 만들 수 있습니다. 이는 공격자가 원하는 어떠한 데이터도 JWT에 넣을 수 있다는 것을 의미하며, 이 토큰은 서버에서 유효한 토큰으로 인식됩니다. 따라서 공격자는 다른 사용자의 권한을 얻거나 서버에서 금지된 작업을 수행할 수 있게 됩니다.
2. 해결방안: Secret Key의 유출을 방지하거나 해결하기 위한 주요 방법은 다음과 같습니다:

만약 Secret Key가 이미 유출되었다면, 즉시 Key를 변경하고 모든 시스템에서 사용되는 해당 Key를 업데이트해야 합니다. 또한 공격자가 이 Key를 사용하여 수행한 모든 작업을 검토하고, 필요한 경우 이를 수정하거나 취소해야 합니다.

 

14. JWT의 보안 문제와 그에 대한 해결책에 대해 알고 계신가요?

JWT(Json Web Token)는 자체적인 정보를 가지고 있는 독립적인 토큰이지만, 이로 인해 보안 문제가 발생할 수 있습니다.

1. Token을 탈취당한 경우: 만약 토큰이 탈취당하면 공격자는 사용자의 권한으로 시스템에 접근할 수 있습니다. 이를 방지하기 위해서는 HTTPS와 같은 안전한 프로토콜을 사용하여 토큰을 전송해야 합니다. 또한 민감한 작업을 수행할 때마다 사용자의 패스워드를 다시 확인하는 등의 추가적인 보안 조치를 취할 수 있습니다.
2. Token이 만료되지 않는 경우: 기본적으로 JWT는 만료 기간이 없으며, 이로 인해 공격자가 토큰을 무제한으로 사용할 수 있습니다. 이를 방지하기 위해서는 JWT에 짧은 만료 기간을 설정해야 합니다. 토큰이 만료되면 사용자는 다시 로그인하여 새 토큰을 받아야 합니다.
3. Token 내의 정보가 노출되는 경우: JWT의 정보는 기본적으로 암호화되지 않으며, base64 인코딩만으로 변환되므로 누구나 디코딩하여 정보를 볼 수 있습니다. 따라서 민감한 정보는 토큰에 포함시키지 않아야 합니다. 필요하다면 JWT를 암호화하는 추가적인 단계를 거칠 수 있습니다.
4. Secret Key 유출: JWT는 서명 과정에서 Secret Key를 사용합니다. 이 Key가 유출되면 공격자는 원하는 어떤 데이터든지 토큰에 넣고 서명할 수 있습니다. 이러한 문제를 방지하기 위해 Secret Key는 안전한 곳에 보관되어야 하며, 주기적으로 변경되어야 합니다.

15. JWT의 'read only' 특성이란 무엇인가요?

JWT(Json Web Token)의 'read only' 특성은 JWT가 생성된 후 그 내용을 변경할 수 없다는 것을 의미합니다.

JWT는 세 부분으로 구성되어 있습니다: Header, Payload, Signature. 이 세 부분은 각각 base64로 인코딩된 후 '.'로 연결되어 하나의 문자열로 만들어집니다. Signature 부분은 Header와 Payload를 서버의 Secret Key로 해시한 결과입니다.

이렇게 생성된 JWT는 원래의 데이터를 그대로 읽을 수 있지만 (base64 디코딩을 통해), 이를 수정하려고 하면 Signature가 더 이상 유효하지 않게 됩니다. 왜냐하면 수정된 Header나 Payload는 원래의 Secret Key로 생성된 Signature와 다른 Signature를 생성하기 때문입니다.

따라서, JWT는 한번 생성되면 그 내용을 변경할 수 없는 'read only' 특성을 가지게 됩니다. 이는 JWT의 보안성을 높여주는 중요한 특성 중 하나입니다.

 

16. JWT를 사용하는 주요 이유와 장점은 무엇인가요?

1. Stateless & Scalability: JWT는 상태를 유지하지 않는(stateless) 방식이기 때문에 서버는 클라이언트의 상태를 기억할 필요가 없습니다. 이로 인해 서버의 부하를 줄이고, 쉽게 확장성을 가질 수 있습니다.
2. Decentralization: JWT는 클라이언트가 토큰을 가지고 있으며, 서버는 토큰의 유효성만을 확인하면 됩니다. 따라서 중앙 서버에서 세션 상태를 관리할 필요가 없어집니다.
3. Cross-Domain / CORS: JWT는 CORS(Cross-Origin Resource Sharing) 문제를 해결하는 데 도움이 됩니다. 쿠키는 동일 출처 정책(Same-Origin Policy) 때문에 다른 도메인 간에 공유하기 어렵지만, JWT는 HTTP 헤더에 포함되어 전송되므로 도메인 간에 쉽게 전송할 수 있습니다.
4. Self-contained: JWT는 필요한 모든 정보를 자체적으로 지니고 있습니다. 토큰 자체가 인증 정보를 가지고 있어서, 별도의 인증 저장소가 필요 없습니다.
5. Performance: 세션 기반의 인증 시스템에서는 매번 사용자의 요청이 있을 때마다 세션 저장소를 조회해야 하지만, JWT에서는 그럴 필요가 없습니다. 이로 인해 성능 향상을 기대할 수 있습니다.

17. JWT의 보안상 문제나 단점은 무엇이며 이를 어떻게 극복할 수 있나요?

1. 토큰의 노출: JWT는 클라이언트 측에서 저장하고 관리하기 때문에 토큰이 노출되거나 탈취당할 위험이 있습니다. 토큰이 탈취되면, 탈취당한 토큰으로 서버에 요청을 보낼 수 있기 때문에 심각한 보안 문제를 일으킬 수 있습니다.
   이를 극복하기 위해 HTTPS와 같은 안전한 채널을 통해 토큰을 전송하고, 보안이 강화된 클라이언트 측 저장소에 토큰을 저장해야 합니다. 또한, 토큰의 만료 시간을 짧게 설정하여 탈취당한 토큰이 오랫동안 사용되지 않도록 하는 것도 중요합니다.
2. 토큰의 크기: JWT는 페이로드에 클레임 데이터를 포함하므로, 세션 ID와 비교해 크기가 큽니다. 큰 토큰은 클라이언트와 서버 사이의 요청에 부하를 줄 수 있습니다.
   이는 필요한 최소한의 데이터만 토큰에 포함하는 것으로 어느 정도 해결할 수 있습니다.
3. 토큰의 만료 처리: JWT는 상태를 저장하지 않는 특성 상, 한 번 발급된 토큰을 서버 측에서 강제로 만료시키는 것이 어렵습니다.
   이 문제는 토큰의 만료 시간을 짧게 설정하고, 필요한 경우 새 토큰을 재발급하는 방식으로 해결할 수 있습니다. 또는 토큰의 블랙리스트를 관리하는 방법도 있습니다만, 이는 서버에서 상태를 관리해야 한다는 점에서 JWT의 stateless한 특성을 손상시킵니다.
4. Secret Key의 보안: Secret Key는 서명을 생성하고 검증하는데 사용되므로, 이 Key가 유출되면 토큰이 위변조 될 수 있습니다.
   Secret Key의 안전한 관리가 필요하며, 주기적인 Key의 갱신도 중요합니다.
5. 개인 정보의 암호화: JWT의 페이로드는 Base64로 인코딩되어 전송되므로, 중요한 개인 정보는 반드시 추가적으로 암호화해야 합니다.

18. 어떤 상황에서 JWT를 사용하면 안될까요?

JWT(Json Web Token)는 인증 정보를 안전하게 보호하기 위해 암호화를 사용합니다. JWT 토큰은 세 부분으로 이루어져 있습니다: Header, Payload, Signature.

1. Header: 암호화에 사용될 알고리즘을 명시합니다.
2. Payload: 인증 및 추가 데이터를 포함합니다.
3. Signature: Header와 Payload, 그리고 비밀 키를 이용해 생성됩니다. 이 Signature는 JWT가 변경되지 않았음을 확인하는 데 사용됩니다.

JWT는 Header와 Payload를 각각 Base64Url로 인코딩하여, 이 둘을 합친 뒤 비밀 키를 이용해 Signature를 생성합니다. 생성된 JWT는 Header, Payload, Signature가 점(.)으로 연결된 형태로 제공됩니다.

즉, JWT 토큰은 이 세 부분을 암호화 및 인코딩하여 토큰의 무결성을 보장하고, 누군가 토큰을 수정하려 하면 Signature가 변경되어 토큰이 무효화되는 방식으로 안전성을 보장합니다. 그러나, Header와 Payload는 Base64로 인코딩되는 것이지, 암호화되는 것은 아닙니다. 따라서, 중요한 개인 정보는 JWT에 포함되지 않아야 합니다.

이처럼 JWT는 자체적으로 인증 정보를 안전하게 보호하며, 이는 서버와 클라이언트 사이에서 안전하게 인증 정보를 주고 받을 수 있게 합니다.

 

19. JWT는 어떻게 인증 정보를 안전하게 보호하나요?

JWT(Json Web Token)는 다음과 같은 방법으로 인증 정보를 보호합니다.

1. 암호화된 서명: JWT는 Header, Payload, 그리고 Secret Key를 사용해 서명을 생성합니다. 이 서명은 JWT가 중간에 조작되지 않았음을 확인하는 데 사용되며, 만약 JWT가 변경되면, 서명이 더 이상 유효하지 않게 되므로 JWT가 무효화됩니다. 따라서 이 서명을 통해 인증 정보의 무결성을 보장합니다.
2. 비공개 클레임: JWT의 Payload 부분에는 클레임이라는 여러 정보들이 들어갑니다. 이 클레임 중 비공개 클레임은 사용자의 인증에 관한 데이터를 포함하고 있어 인증 정보를 보호하는 데 사용됩니다.
3. HTTPS의 사용: JWT 자체가 암호화된 형태는 아니기 때문에, JWT를 전송할 때는 HTTPS와 같은 보안 프로토콜을 통해 전송되어야 합니다. 이를 통해 중간에 JWT가 노출되는 것을 방지할 수 있습니다.
4. Access Token과 Refresh Token의 사용: JWT를 이용한 인증 시스템에서는 일반적으로 Access Token과 Refresh Token 두 가지 토큰을 사용합니다. Access Token은 짧은 만료 시간을 가지고 있어, 토큰이 노출되더라도 노출 시간을 최소화할 수 있습니다. 만료된 Access Token은 Refresh Token을 사용해 갱신할 수 있습니다.

그러나, JWT는 데이터를 암호화하는 것이 아니므로 중요한 개인 정보는 포함되지 않아야 합니다. Header와 Payload는 Base64로 인코딩되는 것이지만, 이는 암호화된 형태가 아니므로, 이를 디코딩하면 원래의 데이터를 볼 수 있습니다. 따라서 민감한 정보를 안전하게 보호하려면 추가적인 암호화 measures가 필요합니다.

 

20. JWT에 저장할 수 있는 정보의 종류와 한계는 무엇인가요?

JWT에는 크게 세 가지 종류의 클레임(claims)이 저장될 수 있습니다:

1. Registered Claims: 토큰의 발행자(iss), 주제(sub), 수신자(aud), 만료 시간(exp), 발행 시간(iat) 등과 같이 프리데파인된 set입니다. 이들은 선택적이지만 권장됩니다.
2. Public Claims: 공개적으로 사용되는 클레임들로, 충돌을 방지하기 위해 IANA JSON Web Token Registry 또는 URI 형식의 이름을 사용해야 합니다.
3. Private Claims: 두 파티 사이에서 합의한 클레임으로, 사용자 정의 클레임이라고도 합니다.

JWT에 저장할 수 있는 정보의 한계는 다음과 같습니다:

• 보안: JWT는 토큰이 변경되지 않았음을 확인하는 서명을 제공하지만, 토큰 자체는 암호화되지 않습니다. 따라서 JWT에는 민감한 정보(예: 비밀번호)를 저장하지 않아야 합니다. 그렇지 않으면, 누군가가 토큰을 가로채어 그 내용을 읽을 수 있습니다.
• 크기: JWT는 HTTP 헤더에 종종 포함되므로, 너무 큰 토큰은 네트워크 성능에 부정적인 영향을 줄 수 있습니다. 또한, 모든 웹 서버와 브라우저는 헤더 크기에 제한을 두고 있으므로, 이 제한을 초과하는 JWT는 전송되지 않을 수 있습니다. 이러한 이유로, JWT에 저장되는 정보는 최소한으로 유지해야 합니다.
• 수명: JWT에는 만료 시간(exp)이 포함될 수 있지만, 한번 발행된 JWT는 중앙 서버가 만료를 강제할 방법이 없습니다. 따라서 JWT는 가능한 짧은 수명을 가져야 하며, 민감한 작업에는 사용되어서는 안됩니다.

21. 사용자 인증을 위해 세션 대신 JWT를 사용하는 이유는 무엇인가요?

JWT를 사용하는 주요 이유는 서버의 세션 상태를 유지하지 않아도 사용자 인증을 구현할 수 있기 때문입니다. 이는 "Stateless"한 아키텍처를 구현하는데 도움이 됩니다.

세션 기반 인증에서는 서버 메모리에 세션 상태를 유지해야 합니다. 사용자가 로그인하면 세션 ID가 생성되고, 이 ID는 쿠키를 통해 클라이언트에게 전달됩니다. 클라이언트는 이후 요청마다 이 세션 ID를 포함하여 서버에 전송하며, 서버는 이 세션 ID를 통해 해당 사용자를 식별합니다. 이 경우, 서버는 모든 활성 사용자에 대한 세션을 메모리에 유지해야 하므로, 세션 수가 많아질수록 서버의 부하가 증가합니다.

반면에, JWT 인증 방식에서는 사용자 상태를 서버 메모리에 저장하지 않습니다. 대신, 서버는 로그인 시 사용자 정보를 JWT 형태로 암호화하여 클라이언트에게 전달합니다. 클라이언트는 이후 요청마다 이 JWT를 포함하여 서버에 전송하고, 서버는 이 JWT를 해독하여 사용자를 인증합니다. 이렇게 하면 서버는 사용자 상태를 유지할 필요가 없으므로, 부하를 줄이고 확장성을 향상시킬 수 있습니다.

또한, JWT는 자체 포함적인(JWT 자체에 사용자 정보가 포함되어 있는) 특성 덕분에, 서버와 클라이언트 간에 상태 정보를 쉽게 주고받을 수 있으므로, 분산 시스템과 마이크로서비스 아키텍처에서 유용하게 사용될 수 있습니다.

 

22.  JWT와 OAuth의 차이점은 무엇인가요?

JWT(Json Web Token)와 OAuth는 모두 인증에 관련된 개념이지만, 다른 목적과 방식으로 사용됩니다.

1. JWT(Json Web Token): JWT는 정보의 신뢰성을 확인할 수 있는 암호화된 문자열입니다. JWT는 토큰에 정보를 담아서 보내는 방식으로, 이 정보는 사용자 인증에 필요한 정보나 데이터 전송 등에 사용됩니다. JWT는 stateless한 인증 방식을 지원하며, 서버가 사용자의 상태를 기억하지 않아도 사용자를 인증할 수 있는 방식입니다.
2. OAuth: 반면에 OAuth는 인증을 위한 open standard 프로토콜로, 사용자가 인터넷 애플리케이션들이 자신의 정보에 접근할 수 있는 권한을 부여하는데 사용됩니다. 즉, 사용자가 직접 ID와 비밀번호를 입력하지 않아도, Google이나 Facebook 등의 계정을 통해 다른 웹 서비스에 로그인하는 것을 가능하게 합니다.

이 두 기술은 서로 다른 목적을 가지고 있지만, 함께 사용될 수도 있습니다. 예를 들어, OAuth를 사용하여 사용자의 권한을 부여받은 후, 해당 권한을 JWT로 암호화하여 클라이언트와 서버 사이에 주고받을 수 있습니다. 이렇게 하면 클라이언트는 JWT를 사용하여 인증을 유지하면서, OAuth를 사용하여 새로운 인증을 받을 수 있습니다.

 

23. JWT는 어떤 식으로 로그아웃을 처리하나요? 그리고 이를 통해 어떤 문제가 발생할 수 있나요?

JWT (Json Web Token)는 자체적으로 로그아웃 기능을 제공하지 않습니다. JWT는 토큰이 만료되거나 클라이언트 측에서 토큰을 삭제할 때까지 유효하기 때문입니다.

로그아웃을 처리하기 위한 일반적인 방법은 클라이언트 측에서 JWT를 삭제하는 것입니다. 클라이언트에서 JWT를 저장하고 있는 공간(예: 쿠키, 로컬 스토리지 등)에서 토큰을 제거하면, 클라이언트는 더 이상 해당 토큰을 사용할 수 없으므로 인증도 해제되는 것과 같습니다.

하지만 이 방식은 중요한 보안 문제를 가지고 있습니다. JWT가 삭제되지 않고 남아있는 경우, 해당 토큰이 유효한 동안은 서버에서 계속 인증을 받게 됩니다. 이로 인해 토큰이 탈취당하면 공격자가 사용자를 가장할 수 있는 문제가 발생할 수 있습니다.

이 문제를 해결하기 위한 한 가지 방법은 서버 측에서 JWT의 블랙리스트를 유지하는 것입니다. 로그아웃 시, 클라이언트에서 JWT를 삭제하고, 해당 토큰을 서버의 블랙리스트에 추가합니다. 이후 이 토큰이 서버에 전송되면, 서버는 블랙리스트에 있는 토큰인지 확인하고, 있으면 인증을 거부합니다. 그러나 이 방법은 추가적인 서버 자원을 사용하게 되며, 일종의 상태를 유지하는 것이기 때문에 JWT가 목표로 하는 stateless한 특성을 상실하게 됩니다.

따라서 JWT의 유효 시간을 짧게 설정하고 적절한 리프레시 토큰(refresh token) 전략을 사용하는 것이 중요합니다. 이렇게 하면 잠재적인 보안 위협을 줄일 수 있습니다.

 

24. 클라이언트가 JWT를 수정하려고 시도한다면 어떻게 대처하나요?

JWT는 페이로드와 헤더를 서명하는 방식으로 무결성을 보장합니다. 서명은 헤더, 페이로드, 그리고 비밀 키(secret key)를 사용하여 생성됩니다.

클라이언트가 JWT의 페이로드 또는 헤더를 변경하면, 서명이 더 이상 유효하지 않게 됩니다. 왜냐하면 변경된 페이로드 또는 헤더와 원래의 비밀 키를 사용하여 생성된 새로운 서명은 원래의 서명과 일치하지 않기 때문입니다.

따라서 클라이언트가 JWT를 변경하려고 시도하면, 서버는 변경된 토큰의 서명이 유효하지 않다는 것을 알 수 있습니다. 이런 경우, 서버는 변경된 토큰을 거부하고, 그에 따른 적절한 에러 메시지를 반환할 수 있습니다. 이러한 방식으로 JWT는 무결성을 보장하며, 토큰의 정보가 중간에 변경되는 것을 방지합니다.

단, 이러한 보안 메커니즘이 정상적으로 작동하려면 비밀 키가 안전하게 보관되어야 합니다. 비밀 키가 유출되면 공격자가 유효한 서명을 생성할 수 있으므로, 비밀 키의 보안은 매우 중요합니다.

 

25. Refresh Token과 JWT는 어떤 관계가 있나요?

JWT (Json Web Token)과 Refresh Token은 모두 사용자 인증에 사용되지만, 각각 다른 목적을 가지고 있습니다.

JWT는 사용자의 인증 정보를 담고 있어, 이를 통해 사용자가 시스템의 어떤 자원에 접근할 수 있는지를 결정합니다. 하지만 보안상의 이유로 JWT의 만료 시간은 상대적으로 짧게 설정되는 경우가 많습니다. 따라서 사용자가 오랜 시간 동안 시스템을 이용하기 위해서는 JWT를 주기적으로 갱신해야 합니다.

이 때, 사용자가 매번 로그인을 통해 새로운 JWT를 받는 것은 불편할 수 있습니다. 이를 해결하기 위해 Refresh Token이 사용됩니다. Refresh Token은 장시간 동안 유효하며, 이를 사용하여 새로운 JWT를 발급받을 수 있습니다. 사용자는 로그인을 통해 JWT와 Refresh Token을 모두 받고, JWT가 만료될 때마다 Refresh Token을 사용해 새로운 JWT를 받습니다.

이렇게 하면 사용자는 로그인 없이도 안전하게 시스템을 오랜 시간 동안 이용할 수 있습니다. 만약 Refresh Token이 유출되면 공격자가 JWT를 계속 갱신할 수 있으므로, Refresh Token의 보안도 중요합니다. 일반적으로 Refresh Token은 보안이 잘 강화된 서버에서 관리되며, 클라이언트에서는 접근할 수 없도록 합니다.

 

26. 토큰 기반 인증 시스템에서 JWT는 어떤 역할을 하나요?

토큰 기반 인증 시스템에서 JWT(Json Web Token)는 클라이언트와 서버 간의 인증을 담당하는 중요한 역할을 합니다.

1. 인증 정보의 전달: 클라이언트가 처음으로 인증을 완료하면, 서버는 JWT를 생성하여 클라이언트에게 제공합니다. 이 JWT는 클라이언트의 인증 정보를 담고 있으며, 이를 클라이언트가 보관하게 됩니다.
2. 요청 시 인증 정보의 확인: 클라이언트는 서버에 요청을 보낼 때마다 이 JWT를 함께 보냅니다. 서버는 이 JWT를 받아 복호화하고, 그 안에 있는 인증 정보를 확인합니다. 만약 JWT가 유효하다면, 요청을 처리하고 그 결과를 클라이언트에게 보내주게 됩니다.
3. 인증 정보의 갱신: JWT는 일정 시간이 지나면 만료되므로, 클라이언트는 새로운 JWT가 필요할 수 있습니다. 이때는 보통 Refresh Token을 이용해서 새로운 JWT를 받게 됩니다.

따라서 JWT는 토큰 기반 인증 시스템에서 인증 정보의 전달, 요청 시 인증 정보의 확인, 인증 정보의 갱신 등의 중요한 역할을 수행하게 됩니다.

 

27. JWT의 만료 시간(exp)은 어떻게 설정되나요?

JWT의 만료 시간(exp)은 생성 시점에 설정되며, 이는 JWT의 페이로드(Payload) 부분에 "exp"라는 필드로 저장됩니다. 이 "exp" 필드는 JWT가 언제 만료될지를 나타내는 Unix 시간 스탬프입니다.

JWT를 생성할 때, "exp" 필드에 특정 시간 값을 넣어주면 그 시간이 지나면 JWT는 자동으로 만료됩니다. JWT를 검증할 때, 현재 시간과 "exp" 필드의 시간을 비교하여 JWT가 아직 유효한지, 아니면 만료되었는지를 판단합니다.

이렇게 만료 시간을 설정함으로써, 서버는 장기간 사용되지 않는 토큰이 시스템을 오염시키는 것을 방지하고, 또한 만약 토큰이 도난당했다면 그 피해를 최소화할 수 있습니다.

"exp" 필드의 값 설정은 보통 JWT를 생성하는 라이브러리나 프레임워크에서 제공하는 기능을 통해 이루어집니다. 개발자는 이 값을 직접 지정하거나, 예를 들어 "5분 후", "24시간 후"와 같이 상대적인 시간을 설정할 수도 있습니다.

 

28. JWT와 쿠키/세션을 함께 사용하는 것이 가능한가요? 그렇다면 어떤 장점이 있나요?

JWT와 쿠키/세션을 함께 사용하는 것이 가능합니다. 사실, 종종 JWT는 쿠키를 통해 클라이언트와 서버 사이에 전달되곤 합니다. 이런 방식에는 몇 가지 장점이 있습니다:

1. 보안성 강화: HTTPS를 사용하는 경우, Secure 쿠키 옵션을 활성화함으로써 JWT를 안전하게 전송할 수 있습니다. 또한, HttpOnly 쿠키 옵션을 사용하면, 쿠키가 JavaScript에서 접근할 수 없게 설정됩니다. 이를 통해 XSS(Cross-Site Scripting) 공격을 방지할 수 있습니다.
   HTTP 쿠키는 Secure 플래그와 HttpOnly 플래그를 사용하여 추가 보안을 제공합니다. Secure 플래그가 설정되면 쿠키는 HTTPS 연결을 통해서만 전송됩니다. 이로 인해 중간자 공격을 통한 토큰 유출을 방지할 수 있습니다. 또한, HttpOnly 플래그가 설정되면 JavaScript를 통해 쿠키에 접근하는 것을 막습니다. 이는 크로스 사이트 스크립팅(XSS) 공격으로부터 쿠키를 보호합니다.
   상태 유지: 쿠키는 웹 브라우저가 자동으로 관리하므로, 클라이언트 측에서 별도로 상태를 유지할 필요가 없습니다. 반면, JWT가 Local Storage나 Session Storage에 저장되는 경우에는 클라이언트 애플리케이션이 명시적으로 이를 관리해야 합니다.
   JWT를 사용하면 클라이언트의 상태를 서버에 저장하지 않고 클라이언트 측에 저장할 수 있습니다. 이는 서버가 클라이언트의 요청이 각각 독립적으로 처리될 수 있게 하는데 도움이 됩니다. 쿠키와 세션을 사용하면 클라이언트의 상태 정보를 서버에서 관리할 수 있으므로, JWT를 쿠키에 저장하면 이 두 가지 접근법의 이점을 동시에 얻을 수 있습니다.
2. 크로스 도메인 문제 해결: 일부 상황에서는 쿠키가 다른 도메인간에 공유되지 않는 문제가 있을 수 있습니다. 이 경우, JWT를 사용하면 도메인 간 인증을 쉽게 처리할 수 있습니다.
   JWT는 도메인 간에 전송될 수 있습니다. 따라서, 클라이언트와 서버가 다른 도메인에 있거나, 서비스가 여러 도메인을 걸쳐서 제공되는 경우에도 인증 정보를 쉽게 전송할 수 있습니다. 이는 쿠키가 같은 도메인에서만 공유될 수 있다는 제한을 해결할 수 있습니다.

그러나 JWT를 쿠키에 저장하는 것에는 주의해야 할 점도 있습니다. 만약 JWT가 쿠키에 저장되면 CSRF(Cross-Site Request Forgery) 공격에 취약해질 수 있습니다. CSRF(Cross-Site Request Forgery)는 공격자가 사용자를 속여서 그들의 의도와는 무관하게 악성 요청을 보내는 공격입니다. 쿠키는 브라우저에서 자동으로 포함되므로, JWT가 쿠키에 있다면 CSRF 공격의 대상이 될 수 있습니다. 이를 방지하기 위해서는 CSRF 토큰과 같은 추가적인 보안 메커니즘을 사용해야 합니다.

결론적으로, JWT와 쿠키/세션을 함께 사용하는 것은 애플리케이션의 보안성, 확장성, 유연성 등에 대한 균형을 맞추는 데 도움이 될 수 있습니다.

 

29. 각 종 세션 관리 방법(쿠키, 세션, JWT 등)을 효과적으로 사용하기 위한 가장 중요한 기준이나 전략은 무엇인가요?

1. 보안성:

어떤 세션 관리 방법을 선택하든지 간에, 보안은 항상 우선적으로 고려해야 합니다. 예를 들어, 세션 ID나 JWT는 반드시 안전하게 보관되어야 하며, 쿠키의 경우에는 HttpOnly와 Secure 플래그를 사용하여 클라이언트 측 스크립트나 네트워크 공격자로부터 보호해야 합니다.

2. 확장성:

시스템의 규모나 사용자 수가 증가함에 따라 세션 관리 방법도 이를 지원할 수 있도록 확장성이 고려되어야 합니다. 예를 들어, JWT는 상태를 클라이언트 측에 저장하므로 서버의 부하를 줄이고 확장성을 증가시키는데 유용합니다.

3. 사용 편의성과 유연성:

세션 관리 방법은 사용자의 경험에 영향을 미칩니다. 예를 들어, 사용자가 로그아웃하지 않고 브라우저를 닫을 경우 세션을 유지할 것인지, 아니면 다시 로그인을 요구할 것인지 결정해야 합니다. 이는 사용자의 편의성과 보안 간의 균형을 맞추는 문제입니다.

4. 성능:

세션 관리 방법은 애플리케이션의 성능에도 영향을 미칩니다. 서버 측에 상태 정보를 저장하는 세션은 서버의 메모리를 사용하므로, 많은 양의 동시 사용자를 처리하는 데 문제가 될 수 있습니다. 반면 JWT는 클라이언트 측에 상태를 저장하지만, 이는 네트워크 트래픽을 증가시킬 수 있습니다.

5. 유지보수성:

세션 관리 방법은 유지보수성을 고려하여 선택되어야 합니다. 예를 들어, JWT의 경우 비밀 키를 관리하고 토큰을 갱신하는 등의 작업이 필요합니다.

 

2023.05.29 - [Web] - Cookie, Session, JWT(Json Web Token) pt.1