서론: 정적 인증 정책의 한계와 새로운 대안
사용자 인증은 이제 단순히 '로그인 성공/실패'를 넘어서, 그 세션이 얼마나 안전한지를 평가해야 하는 시대입니다. 비밀번호 유출, 세션 하이재킹, 계정 탈취 같은 공격이 갈수록 정교해지면서, 모든 요청을 동일한 신뢰 수준으로 처리하는 기존 방식은 위험합니다.
Google은 이런 문제를 해결하기 위해 **Sign in with Google에 세션 메타데이터 클레임(auth_time, amr)**을 새로 도입했습니다. 이 클레임들은 ID 토큰에 포함되어 백엔드 시스템이 사용자의 인증 시점과 인증 방법을 파악할 수 있게 해줍니다. 이를 통해 더 동적인, 위험 기반의 접근 제어를 구현할 수 있습니다.
이 글에서는 두 클레임의 의미와 활용법, 그리고 실제 서비스에 적용할 때 고려할 점을 살펴보겠습니다.
본론 1: auth_time과 amr 클레임 이해하기
auth_time (인증 시간)
auth_time은 사용자가 Google 계정에 마지막으로 인증한 시각을 나타냅니다. 이 값은 **세션의 신선도(freshness)**를 판단하는 핵심 지표입니다. 예를 들어, 사용자가 1시간 전에 Google에 로그인했다면, 그 세션은 비교적 최근에 검증된 것으로 볼 수 있습니다.
amr (인증 방법 참조)
amr은 사용자가 인증할 때 사용한 방법을 나타내는 값입니다. 주요 값은 다음과 같습니다:
pwd: 비밀번호 사용mfa: 다중 인증(MFA) 챌린지 완료hwk: 하드웨어 보안 키 사용swk: 소프트웨어 보안 키 사용tel: 전화 인증sms: SMS 인증
이 값들을 조합하면 인증의 강도를 정확히 평가할 수 있습니다. 예를 들어, hwk 값이 있으면 하드웨어 키를 사용한 강력한 인증임을 알 수 있습니다.
실제 코드 예제
OIDC 표준에 따라 ID 토큰에 클레임을 요청하는 방법은 간단합니다. 다음은 인증 요청 URL 예시입니다.
# 인증 요청 URL 예시 (Python 코드 아님, URL 구성 예시)
# claims 파라미터로 amr과 auth_time을 필수로 요청합니다.
auth_url = (
"https://accounts.google.com/o/oauth2/v2/auth?"
"response_type=id_token&"
"client_id=YOUR_CLIENT_ID&"
"scope=openid email profile&"
"redirect_uri=https://example.com/user-login&"
"nonce=RANDOM_VALUE&"
"claims={\"id_token\": {\"amr\": {\"essential\": true}, \"auth_time\": {\"essential\": true}}}"
)
print(auth_url) # 실제 요청 시 이 URL로 리다이렉트
이렇게 요청하면 ID 토큰에 amr과 auth_time이 포함되어 전달됩니다. 백엔드에서는 JWT 디코딩 후 이 값들을 추출하여 정책에 활용할 수 있습니다.
# 백엔드에서 ID 토큰 디코딩 예시 (jwt 라이브러리 사용)
import jwt
# 토큰 검증 후 claims 추출
decoded = jwt.decode(id_token, options={"verify_signature": False})
auth_time = decoded.get("auth_time")
amr = decoded.get("amr")
# 예: 민감한 작업 전에 amr에 mfa가 있는지 확인
if "mfa" not in amr:
raise PermissionError("MFA 인증이 필요합니다.")
위험 기반 접근 제어 구현 아이디어
- 민감한 작업에 단계적 인증(Step-up) 적용:
auth_time이 오래된 경우, 비밀번호 변경이나 결제와 같은 민감한 동작 전에 추가 인증을 요구할 수 있습니다. - 관리자 기능 접근 제한:
amr에hwk또는mfa가 없으면 관리자 기능에 접근하지 못하도록 차단할 수 있습니다. - 감사 로그 기록:
amr값을 기록하여 어떤 인증 방법으로 접근했는지 추적할 수 있습니다.
본론 2: 주의사항 및 심화 팁
검증된 앱만 사용 가능
이 클레임들은 검증된 애플리케이션에서만 사용할 수 있습니다. 즉, Google Cloud Console에서 앱 검증을 완료해야 합니다. 아직 검증되지 않았다면 OAuth 동의 화면 설정에서 검증 절차를 진행하세요.
기존 인증 흐름과의 호환성
기존 Sign in with Google 흐름을 변경할 필요 없이, 단지 claims 파라미터만 추가하면 됩니다. 따라서 마이그레이션 비용이 낮습니다.
개인정보 보호 고려
auth_time과 amr은 민감한 정보입니다. 이 값을 저장하거나 로깅할 때는 개인정보 보호 정책에 주의해야 합니다. 특히, GDPR과 같은 규정을 준수해야 합니다.
한국 개발 생태계에서의 적용 맥락
국내 서비스에서는 간편 로그인(카카오, 네이버)이 널리 사용되지만, 글로벌 서비스를 목표로 한다면 Google Sign-in이 여전히 중요합니다. 특히, 금융, 커머스 등 보안이 중요한 서비스에서 이 클레임을 활용하면 규제 요구사항(예: 전자금융거래법)을 충족하는 데 도움이 될 수 있습니다. 다만, 사용자 경험을 해치지 않도록 단계적 인증의 기준을 신중히 설계해야 합니다.
이 기술의 한계
- Google 세션에 의존:
auth_time은 Google 세션 기준이므로, 사용자가 Google에 오래 로그인되어 있어도 앱에서의 활동 시간과는 다를 수 있습니다. - amr 값의 다양성: 일부 인증 방법은 조합으로 나타날 수 있어 해석에 주의가 필요합니다.
- 검증 앱 제한: 소규모 앱은 검증 절차가 번거로울 수 있습니다.
결론: 실무 적용 조언
이번 업데이트는 Google이 이미 검증한 인증 정보를 여러분의 서비스가 그대로 활용할 수 있게 해주는 강력한 기능입니다. 정적 정책에서 벗어나 동적이고 위험 기반의 접근 제어를 구현하고 싶다면, 이 클레임들이 좋은 출발점이 될 것입니다.
다음 단계로는, 실제 백엔드에서 JWT 검증 시 서명 검증을 반드시 수행하고, 클레임 값에 대한 테스트 코드를 작성하는 것을 권장합니다. 또한, Google Identity 문서에서 추가 예제를 확인해 보세요.
함께 보면 좋은 글:
- TorchTPU, 구글이 PyTorch를 TPU에서 네이티브로 돌리기 위해 만든 비밀 병기
- 클라우드 연결이 끊겨도 안전하게 AI를 구동하는 법 - Microsoft Sovereign Cloud 업데이트 핵심
본론 1: auth_time과 amr 클레임 이해하기
auth_time (인증 시간)
auth_time은 사용자가 Google 계정에 마지막으로 인증한 시각을 나타냅니다. 이 값은 **세션의 신선도(freshness)**를 판단하는 핵심 지표입니다. 예를 들어, 사용자가 1시간 전에 Google에 로그인했다면, 그 세션은 비교적 최근에 검증된 것으로 볼 수 있습니다.
amr (인증 방법 참조)
amr은 사용자가 인증할 때 사용한 방법을 나타내는 값입니다. 주요 값은 다음과 같습니다:
pwd: 비밀번호 사용mfa: 다중 인증(MFA) 챌린지 완료hwk: 하드웨어 보안 키 사용swk: 소프트웨어 보안 키 사용tel: 전화 인증sms: SMS 인증
이 값들을 조합하면 인증의 강도를 정확히 평가할 수 있습니다. 예를 들어, hwk 값이 있으면 하드웨어 키를 사용한 강력한 인증임을 알 수 있습니다.
실제 코드 예제
OIDC 표준에 따라 ID 토큰에 클레임을 요청하는 방법은 간단합니다. 다음은 인증 요청 URL 예시입니다.
# 인증 요청 URL 예시 (Python 코드 아님, URL 구성 예시)
# claims 파라미터로 amr과 auth_time을 필수로 요청합니다.
auth_url = (
"https://accounts.google.com/o/oauth2/v2/auth?"
"response_type=id_token&"
"client_id=YOUR_CLIENT_ID&"
"scope=openid email profile&"
"redirect_uri=https://example.com/user-login&"
"nonce=RANDOM_VALUE&"
"claims={\"id_token\": {\"amr\": {\"essential\": true}, \"auth_time\": {\"essential\": true}}}"
)
print(auth_url) # 실제 요청 시 이 URL로 리다이렉트
이렇게 요청하면 ID 토큰에 amr과 auth_time이 포함되어 전달됩니다. 백엔드에서는 JWT 디코딩 후 이 값들을 추출하여 정책에 활용할 수 있습니다.
# 백엔드에서 ID 토큰 디코딩 예시 (jwt 라이브러리 사용)
import jwt
# 토큰 검증 후 claims 추출
decoded = jwt.decode(id_token, options={"verify_signature": False})
auth_time = decoded.get("auth_time")
amr = decoded.get("amr")
# 예: 민감한 작업 전에 amr에 mfa가 있는지 확인
if "mfa" not in amr:
raise PermissionError("MFA 인증이 필요합니다.")
본론 2: 주의사항 및 심화 팁
검증된 앱만 사용 가능
이 클레임들은 검증된 애플리케이션에서만 사용할 수 있습니다. 즉, Google Cloud Console에서 앱 검증을 완료해야 합니다. 아직 검증되지 않았다면 OAuth 동의 화면 설정에서 검증 절차를 진행하세요.
기존 인증 흐름과의 호환성
기존 Sign in with Google 흐름을 변경할 필요 없이, 단지 claims 파라미터만 추가하면 됩니다. 따라서 마이그레이션 비용이 낮습니다.
개인정보 보호 고려
auth_time과 amr은 민감한 정보입니다. 이 값을 저장하거나 로깅할 때는 개인정보 보호 정책에 주의해야 합니다. 특히, GDPR과 같은 규정을 준수해야 합니다.
한국 개발 생태계에서의 적용 맥락
국내 서비스에서는 간편 로그인(카카오, 네이버)이 널리 사용되지만, 글로벌 서비스를 목표로 한다면 Google Sign-in이 여전히 중요합니다. 특히, 금융, 커머스 등 보안이 중요한 서비스에서 이 클레임을 활용하면 규제 요구사항(예: 전자금융거래법)을 충족하는 데 도움이 될 수 있습니다. 다만, 사용자 경험을 해치지 않도록 단계적 인증의 기준을 신중히 설계해야 합니다.
이 기술의 한계
- Google 세션에 의존:
auth_time은 Google 세션 기준이므로, 사용자가 Google에 오래 로그인되어 있어도 앱에서의 활동 시간과는 다를 수 있습니다. - amr 값의 다양성: 일부 인증 방법은 조합으로 나타날 수 있어 해석에 주의가 필요합니다.
- 검증 앱 제한: 소규모 앱은 검증 절차가 번거로울 수 있습니다.
결론: 실무 적용 조언
이번 업데이트는 Google이 이미 검증한 인증 정보를 여러분의 서비스가 그대로 활용할 수 있게 해주는 강력한 기능입니다. 정적 정책에서 벗어나 동적이고 위험 기반의 접근 제어를 구현하고 싶다면, 이 클레임들이 좋은 출발점이 될 것입니다.
다음 단계로는, 실제 백엔드에서 JWT 검증 시 서명 검증을 반드시 수행하고, 클레임 값에 대한 테스트 코드를 작성하는 것을 권장합니다. 또한, Google Identity 문서에서 추가 예제를 확인해 보세요.
함께 보면 좋은 글: