• 보안이 매우 약하다 | | 다이제스트 인증 (Digest Authentication) | - Basic Authentication의 보안 단점을 개선하기 위해 설계
• 다이제스트 인증은 사용자의 비밀번호를 직접 전송하지 않고 비밀번호의 해시된 버전을 사용 동작방식:

1. 서버는 nonce를 생성하여 WWW-Authenticate 헤더와 함께 클라이언트에 보낸다.
2. 클라이언트는 이 nonce를 사용하여 자신의 응답(해시 함수를 사용하여 계산)을 생성하고, 이 응답은 서버에서 검증된다. (**Nonce**의 주된 목적은 재전송 공격(replay attacks)을 방지하는 것)
3. 서버는 클라이언트로부터 받은 Authorization 헤더 내의 응답과 서버에서 독립적으로 생성한 해시 값을 비교한다. | | Bearer 토큰 (Bearer Token) | 정의: 사용자의 개인 정보와 권한 정보가 포함된 보안된 텍스트 문자열 형태의 토큰 | | | | | Json Web Token | 정의: 애플리케이션 간의 정보 교환을 위해 설계된, 정보를 JSON 형식으로 포함하는 자체 포함형(compact and self-contained) 토큰

• "자체 포함형"이란 표현은 JWT가 모든 팔요 정보를 자체적으로 담고 있다는 의미를 가지고 있다. 이 구조는 JWT가 독립적으로 동작할 수 있도록 해주며, 별도의 추가 데이터베이스 조회 없이도 인증이나 사용자의 권한을 확인할 수 있다. → 사용자의 인증 상태를 유지하면서 서버 간의 부담을 줄이고, 무상태(stateless) 인증을 가능하게 함 | | JWT 구조 | 1. HEADER: 토큰의 유형(ex JWT)과 사용된 서명 알고리즘(ex HS256) 정보

2. PAYLOAD: 사용자 정보를 포함한 클레임(claim)
3. SIGNATURE: 토큰이 변조되지 않았음을 보장하는 암호화된 서명 | | SHA256 | 용도: 데이터의 무결성을 검증하는 데 주로 사용된다. 파일이나 메시지의 해시를 생성하여 저장하고, 나중에 같은 파일이나 메시지로부터 다시 해시를 생성해 원본 해시와 비교함으로써 데이터가 변경되지 않았는지 확인할 수 있다. 특징: SHA256은 일방향 해시 함수로서, 해시 값으로부터 원본 데이터를 복구하는 것은 계산상 불가능하다는 것이 보장됩니다. 이는 데이터의 무결성을 보호하는 데 매우 효과적이다. | | JWT 서명 및 암호화 | SIGNATURE에 포함되어 있는 서명은 헤더와 페이로드를 합친 뒤, 지정된 알고리즘(HS256)으로 해시하고, 비밀키를 사용하여 서명하기 때문에 JWT의 데이터 무결성을 보장한다. | | 세션 기반 인증과의 비교 | JWT의 가장큰 단점은 토큰 탈취 시 토큰이 만료되기 전까지 사용자 행동 가능하다. 세션 기반 인증은 세션 ID는 사용자 정보를 포함하지 않고, 서버에서만 세션 데이터 관리하기 떄문에 보안적으로 우수하다.

하지만 세션 기반 인증 사용자 정보 서버 저장되기 떄문에 대규모 시스템에서 복잡해질수있고 서버에 부하 증가, 확장성 저하를 이르킬수 있다. 반면 JWT는 자체 포함형 토큰이기 떄문에 모든 정보를 자체적으로 저장하기때문에 서버에서 별도로 데이터베이스 필요없다. | | Refresh Token | 정의: JWT 기반 인증 시스템에서 액세스 토큰(Access Token)이 만료되었을 때, 새로운 액세스 토큰을 발급받기 위해 사용되는 토큰 | | | | | OAuth2.0 | 정의: 사용자가 자신의 정보에 대한 접근 권한을 안전하게 타사 애플리케이션에 부여할 수 있게 하는 개방형 표준 프로토콜, 즉 타 웹사이트가 내 아이디와 비밀번호를 직접 묻지 않고, 구글을 통해 내 정보를 받아오는 방식 | | OAuth 1.0과의 차이점 | OAuth 1.0은 보안이 강하지만 구현이 복잡하고 모바일/웹 환경에 적합하지 않다. OAuth 2.0은 더 간단한 토큰 기반 방식을 사용하며 다양한 환경에 적용 가능해서 현재 가장 널리 사용됨. | | 보안 강화 대책 (XSS, CSRF, 토큰 탈취 방지) | 1. 토큰 탈취 방지: HTTPS, PKCE 사용

• PKCE: 인증 요청마다 토큰에 고유한 코드(code_verifier)를 포함

2. CSRF (사이트 간 요청 위조) 방지: State 파라미터 사용

• State 파라미터: 클라이언트(앱)가 로그인 요청을 보낼 때 state 값(랜덤 토큰)을 함께 보낸다 → OAuth 서버는 인증 후, 다시 state 값을 포함해 리디렉트한다 → 클라이언트가 state 값을 비교해 일치하면 정상 요청, 다르면 공격 가능성 있음.

3. XSS (크로스 사이트 스크립팅) 방지: 악성 스크립트를 삽입하여 토큰을 탈취하거나 인증 요청을 조작. ( Access Token이 클라이언트 측(브라우저)에서 노출되면 XSS 공격에 취약할수 있다. )

• Implicit Flow(토큰 직접 노출 방식) 대신 Authorization Code Flow 사용
• 토큰을 로컬 스토리지 대신 Secure HTTP-Only 쿠키에 저장
• CSP(Content Security Policy) 설정으로 악성 스크립트 차단 |

1️⃣ JWT 동작 방식

• 1. 토큰 발급**(Token Issuance)**
• 2. 토큰 전송**(Token Transmission)**
• 3. 토큰 검증**(Token Verification)**

2️⃣ OAuth 동작방식

1. 사용자: 웹사이트 A에서 "구글 계정으로 로그인" 버튼을 누름.
2. 웹사이트 A: 구글에게 "이 사용자가 로그인하고 싶어 합니다"라고 요청.
3. 구글: 사용자가 로그인할 수 있도록 확인 화면을 띄움. (ex: 구글로 로그인하기)
4. 구글: 웹사이트 A에게 "접근 토큰(Access Token)"을 발급해 줌.
5. 웹사이트 A: 이 토큰을 사용해서 구글 API를 통해 사용자 정보(이메일,이름)를 가져옴. → 첫 로그인과 동시에 동시에 웹사이트 A에 회원가입 할 수 있다

• 🌟 면접 예상 질문