[Apple 로그인][보안] Sign in with Apple server-to-server revoked notification을 받은 뒤 session invalidation 로그와 relink 차단 상태를 어떤 순서로 같이 저장하나

IT 리서치 노트

[Apple 로그인][보안] Sign in with Apple server-to-server revoked notification을 받은 뒤 session invalidation 로그와 relink 차단 상태를 어떤 순서로 같이 저장하나

Sign in with Apple에서 credential revoked 상황을 앱 클라이언트만 보고 처리하면, 서버가 받은 revoked notification과 실제 session invalidation 시각이 서로 어긋나기 쉽다. 2026년 8월 31일 KST 기준 Apple 공식 문서를 다시 보면 account change 대응은 server-to-server notifications 구성, notification 검증, 세션과 서버 인프라 업데이트를 함께 전제로 둔다. 이 글은 server-to-server revoked notification을 받은 뒤 session invalidation 로그와 relink 차단 상태를 어떤 순서로 같이 저장해야 하는지 정리한다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 revoked notification을 받았을 때는 세션 무효화와 relink 차단을 같은 incident 흐름에 두되, 서로 다른 상태 칸으로 분리해야 한다. 세션을 바로 끊는 일과, 새로운 relink를 언제 풀지 결정하는 일은 같은 사건이지만 같은 필드가 아니다.

특히 server-to-server notification은 app grouping과 endpoint 구성이 함께 걸려 있으므로 notification id, app group, userIdentifier, session invalidated_at, relink block state를 같은 레코드에 묶는 편이 안전하다.

2. 어디서 실제로 막히는가

현장에서 먼저 꼬이는 지점은 세 가지다. 첫째, 서버는 revoked notification을 받았는데 앱 세션 종료 시각은 안 남긴다. 둘째, 세션은 끊었지만 relink를 막았는지 풀었는지 상태값이 없다. 셋째, 재인증 성공 뒤 새 token mapping과 이전 userIdentifier 관계를 따로 기록하지 않는다.

Apple의 processing changes 문서는 account change 대응을 server-to-server notifications 설정과 검증 흐름으로 연결하고, help 문서는 알림이 app group 단위로 전송된다고 설명한다. TN3194는 앱 데이터와 서버 인프라를 함께 업데이트하라고 안내한다. 즉 revoked handling은 클라이언트 이벤트 하나로 닫히지 않는다.

문제는 실제 운영 메모가 흔히 두 조각으로 나뉜다는 점이다. 인증 서버 티켓에는 notification 수신 사실만 있고, 앱 세션 이슈에는 강제 로그아웃만 적혀 있다. 그러면 사용자가 다시 진입했을 때 왜 relink가 막혔는지, 언제 새 Sign in with Apple을 강제해야 하는지 설명이 길어진다.

• 증상: revoked 알림은 있는데 session invalidation 시각이 없다.
• 실패: 세션 종료와 relink 차단 상태를 같은 boolean으로 처리한다.
• 막힘: app group 기준 notification 맥락을 빼고 userIdentifier만 남긴다.
• 누락: 재인증 뒤 새 mapping과 차단 해제 시점을 기록하지 않는다.

겉으로 보이는 현상	같이 남겨야 할 값	판단 기준
사용자는 로그아웃됐는데 왜 막혔는지 모른다	session_invalidated_at, relink_block_state	세션 종료와 relink 차단을 분리한다
서버 알림 근거가 약하다	notification type, app_group, received_at	어떤 알림을 처리했는지 본다
재인증 후 상태가 꼬인다	new token mapping, unblock_at	새 identity와 차단 해제 시점을 본다

3. 실무에서 적용하는 순서

가장 실용적인 운영 순서는 다섯 단계다. 먼저 notification type과 app group, received_at을 저장한다. 다음으로 기존 세션 invalidation 시각을 바로 찍는다. 세 번째로 relink block state를 blocked-until-reauth 같은 명시적 값으로 기록한다. 네 번째로 사용자가 새 Sign in with Apple을 완료하면 새 token mapping과 unblock 판단을 같은 row에 추가한다. 마지막으로 검증 실패나 서버 오류 케이스는 보수적 제한 상태로 따로 남긴다.

1. notification type, app group, received_at을 먼저 저장한다.
2. session_invalidated_at을 별도 필드로 남긴다.
3. relink 차단 상태를 명시적 상태값으로 기록한다.
4. 재인증 뒤 새 token mapping과 unblock 판단을 덧붙인다.
5. 검증 실패는 수동 검토 상태로 남긴다.

이 구조를 잡아 두면 revoked notification이 왔을 때 클라이언트와 서버가 서로 다른 말을 하지 않게 된다. 세션 종료는 이미 했지만 relink는 아직 막혀 있는지, 아니면 새 인증이 완료돼 block을 풀었는지 한 레코드에서 바로 읽을 수 있다.

notification_type=consent-revoked
app_group=primary-ios-login
session_invalidated_at=2026-08-31T11:42:15+09:00
relink_block_state=blocked-until-reauth
next_action=force-fresh-sign-in

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 Apple의 processing changes 문서다. account change를 처리하려면 server-to-server notifications를 구성하고, 알림을 decode 및 validate해야 한다고 직접 연결해 둔다.

Apple은 account change 대응을 server-to-server notifications 설정과 검증 흐름으로 안내한다.

즉 revoked 알림을 받았을 때 해야 할 일은 단순 재로그인이 아니라, 서버 쪽 상태와 클라이언트 relink 경계를 함께 정리하는 것이다.

두 번째 자료는 server-to-server notifications 설정 도움말이다. 알림이 app group 단위로 오고, 사용자 account change나 mail forwarding preference change를 알려 준다고 적는다.

server-to-server notification은 app grouping 단위로 오므로 session invalidation 로그도 앱 그룹 기준 키를 같이 남겨야 한다.

그래서 relink 차단 상태를 저장할 때 userIdentifier만 보면 부족할 수 있다. 어느 app grouping과 어떤 endpoint에서 온 알림인지 같이 적어야 운영이 덜 꼬인다.

세 번째 자료는 TN3194다. Apple은 Sign in with Apple 계정 변경과 token revocation 대응을 서버 인프라까지 포함해 관리하라고 안내한다.

TN3194는 account deletion과 token revocation을 앱 세션과 서버 인프라 차원에서 함께 다루라고 정리한다.

따라서 revoked notification 처리도 세션 만료 로그와 relink 차단 플래그를 분리하되, 같은 incident note에서 읽히게 해야 한다.

실무에서 가장 자주 섞이는 것은 session invalidation과 relink 차단 상태다. 아래 표는 server-to-server revoked notification을 받은 뒤 어떤 상태표로 먼저 나눌지 정리한 것이다.

revoked notification 뒤에는 session invalidation과 relink 차단 상태를 분리해 같은 상태표에 두는 편이 안전하다.

이미 credential revoked 뒤 relink와 재인증 경계 글이 사용자 흐름을 정리했다면, 이번 글은 서버 알림을 받은 뒤 어떤 로그를 같이 남길지에 집중한다.

마지막 자료는 revoke incident 로그 예시다. 핵심은 notification 수신, 세션 무효화, relink 차단, 재인증 완료가 하나의 레코드 흐름으로 이어지게 만드는 것이다.

server-to-server revoke incident 로그는 session invalidation과 relink block 상태를 같은 record에 묶어야 한다.

이 구조가 있어야 post 437의 first-login-only name, post 440의 userIdentifier relink, post 444의 credential revoked 경계가 실제 운영 메모로 이어진다.

5. 주의사항과 리스크

첫 번째 리스크는 세션 종료와 relink 차단을 같은 boolean으로 처리해 사용자가 다시 왜 로그인해야 하는지 설명이 약해지는 것이다. 두 번째 리스크는 app grouping 맥락을 빼고 userIdentifier만 남겨 어떤 notification 설정에서 온 사건인지 놓치는 것이다. 세 번째 리스크는 재인증 성공 뒤 차단 해제 시점을 안 남겨, 이후 relink 이슈가 다시 났을 때 이전 revoke incident와 연결이 끊기는 것이다.

운영 전에는 notification id, app group, session invalidation 시각, relink block state, reauth 완료 시각 다섯 칸을 같은 incident note에 두는 편이 좋다. 그래야 account deletion이나 relay drift follow-up으로도 자연스럽게 이어진다.

• session invalidation과 relink 차단은 같은 사건이지만 다른 상태다.
• app grouping 맥락을 빼면 server notification 해석이 약해진다.
• 재인증 후 unblock 기록이 없으면 후속 relink audit가 길어진다.

6. 결론

Sign in with Apple revoked notification 대응은 강제 로그아웃 한 줄로 닫히지 않는다. server-to-server 알림 수신, session invalidation, relink 차단, 재인증 후 unblock 판단을 같은 incident 흐름으로 저장하면 Apple 로그인 보안 운영이 훨씬 단단해진다.

같은 Apple 로그인 클러스터를 더 넓게 보려면 새 허브 글인 credential revoked, server-to-server revoked notification, account deletion을 언제 다른 incident로 나눌지 정리한 글을 이어서 보면 좋다. 이번 글이 서버 알림 처리 자체를 다뤘다면, 후속 글은 revoke 계열 사건 셋을 어떤 이름과 후속 조치로 분리할지 정리한다.

• notification 맥락과 세션 종료 시각을 같이 남긴다.
• relink 차단 상태를 명시적 값으로 둔다.
• 재인증 뒤 unblock 판단까지 같은 row로 이어 붙인다.

7. 참고 링크

1. https://developer.apple.com/documentation/signinwithapple/processing-changes-for-sign-in-with-apple-accounts
2. https://developer.apple.com/help/account/capabilities/enabling-server-to-server-notifications/
3. https://developer.apple.com/documentation/technotes/tn3194-handling-account-deletions-and-revoking-tokens-for-sign-in-with-apple
4. https://developer.apple.com/documentation/xcode/configuring-sign-in-with-apple
5. https://developer.apple.com/documentation/signinwithapple/authenticating-users-with-sign-in-with-apple