[TIL] jwt, OAuth2

Soeng_dev·2024년 11월 29일

OAuth 2.0

제3자 애플리케이션이 사용자 비밀번호를 노출하지 않고 자원에 제한된 접근을 할 수 있게 하는 인증 프레임워크.

주요 개념

Resource Owner

데이터나 자원의 소유자 (사용자)

Client

자원에 접근하려는 애플리케이션

Authorization Server

사용자 인증 및 액세스 토큰 발급

Resource Server

자원을 제공하는 서버

인증 방식

Authorization Code Grant

가장 안전한 방식, 웹/모바일 앱 사용.

Client Credentials Grant

클라이언트가 자신의 자원에 접근.

Password Grant

사용자가 클라이언트에 비밀번호 제공, 신뢰된 클라이언트에서 사용.

Implicit Grant

보안 문제로 사용 권장하지 않음.

Device Authorization Grant

브라우저가 없는 디바이스에서 사용.

토큰

토큰 규약

Bearer
Bearer 토큰은 OAuth 2.0에서 주로 사용하는 인증 방식으로, HTTP 요청의 Authorization 헤더에 포함되어 리소스 서버에 전달된다.
특징
Self-contained
JWT로 구현되는 경우가 많고, 자체적으로 인증 정보와 서명을 포함함.
"Bearer"의 의미
토큰 소지자에게 리소스 접근 권한을 부여함. HTTPS 사용 필수.
Stateless
서버는 클라이언트 상태를 저장하지 않고 요청 시 토큰의 유효성만 검증.
사용 방법

Copy code
GET /protected/resource HTTP/1.1
Authorization: Bearer {ACCESS_TOKEN}

OAuth 2.0에서 역할
인증 후 클라이언트가 Access Token 발급받음.
Access Token으로 API 호출.
리소스 서버가 토큰 유효성 검증.

MAC
OAuth 2.0에서 Bearer 토큰과 대비되는 인증 방식으로, 추가적인 보안을 제공하기 위해 메시지에 서명을 포함하는 토큰이다. MAC은 "Message Authentication Code"의 약자로, 요청 데이터와 비밀 키를 기반으로 생성된 인증 코드다.
특징
메시지 서명 포함
클라이언트는 요청마다 토큰과 함께 메시지 서명을 전송하며, 리소스 서버는 이를 검증해 요청의 무결성과 인증 여부를 확인한다.
추가적인 보안
요청 데이터가 위변조되지 않았는지 확인 가능하며, Bearer 토큰보다 더 높은 수준의 보안을 제공.

Stateless
Bearer 토큰처럼 서버는 클라이언트의 상태를 저장하지 않고, 서명을 검증해 요청을 처리.

MAC 토큰 구조
MAC 토큰을 사용하는 요청에는 다음과 같은 정보가 포함됨:

토큰: 클라이언트 인증용.
메시지 서명: 요청 메시지(HTTP 메서드, URL, 요청 바디 등)요청 데이터와 비밀 키를 사용해 생성.
타임스탬프 및 nonce: 재전송 방지.
예시 요청:

http
Copy code
GET /protected/resource HTTP/1.1
Authorization: MAC id="{TOKEN}", ts="1609459200", nonce="abc123", mac="{SIGNATURE}"

Bearer vs MAC

jwt+Bearer vs MAC

종류

Access Token

자원에 접근할 때 사용하는 토큰.

Refresh Token

새 액세스 토큰을 얻기 위한 토큰.

보안 모범 사례

PKCE 사용: 인가 코드 탈취 방지.
HTTPS 사용: 통신 암호화.
Scope 사용: 최소 권한 부여.
OAuth 2.0 구현
Java: Spring Security OAuth
Python: Authlib
Node.js: OAuth2-client

시퀀스 다이어그램

아래 링크 참고
https://blog.naver.com/mds_datasecurity/222182943542

CSRF 참고자료

https://devscb.tistory.com/123

jwt

JWT에 중요한 정보를 넣으면 안 되는 이유

Base64Url 인코딩은 암호화가 아님

JWT의 페이로드는 Base64Url로 인코딩되며, 누구든 디코딩할 수 있음.
따라서 페이로드에 민감한 정보를 넣으면 쉽게 노출됨.
JWT는 클라이언트에게 전달됨

클라이언트는 신뢰할 수 없는 환경(브라우저, 앱 등)에 있음.
민감한 정보가 포함되면 노출 가능성이 커짐.
토큰 탈취 위험

JWT 유출 시 공격자가 이를 악용해 불법적인 접근을 시도할 수 있음.
민감한 정보까지 포함되면 피해가 커짐.
JWT에 포함할 수 있는 정보
사용자 ID (user_id, sub)
사용자 역할(Role) (role, is_admin)
만료 시간 (exp)
특징: 디코딩되더라도 문제가 없는 정보만 포함.

JWT에 포함하면 안 되는 민감한 정보

비밀번호
주민등록번호
신용카드 정보
개인 연락처(이메일, 전화번호 등)
의료 기록 등 민감한 데이터
민감한 정보 포함 대안
JWE(JSON Web Encryption)

민감한 정보 포함 대안

JWE(JSON Web Encryption)

: JWT의 페이로드를 암호화하여 숨김.

참조 토큰(Reference Token)

:민감한 데이터를 직접 넣지 않고, 서버에서 조회 가능한 ID만 포함.

핵심 정리

JWT는 데이터 무결성과 인증에 초점.
누구나 디코딩할 수 있으므로 민감한 정보는 넣지 않음.
민감한 데이터는 별도 보안 방식이나 암호화를 사용해야 함.

profile
Software Engineer

0개의 댓글