1번과 2번 문제는 Apple의 의도적인 구현 선택으로 인해 발생합니다. 따라서 이는 엄밀히 말해 기술적 사고가 아니며, 우회 처리가 가능합니다. 3번 문제는 omniauth-apple gem과 관련되어 있으므로 수정이 가능합니다.
Apple에서 필요한 것은 후속 인증 플로우에서 이름/이메일을 포함시켜 주는 것입니다. 불행히도 Apple은 해당 동작을 인정하면서도, 이는 의도된 동작이라고 밝혔습니다. Security Verification
이는 올바르게 동작합니다. 사용자 정보는 최초 사용자 가입 시에만 ASAuthorizationAppleIDCredential에 포함되어 전송됩니다. 동일한 계정으로 Sign In with Apple을 사용하여 앱에 후속 로그인할 경우 사용자 정보는 공유되지 않으며, ASAuthorizationAppleIDCredential에는 사용자 식별자만 반환됩니다. 서버에서 계정이 성공적으로 생성되었음을 검증할 수 있을 때까지 사용자 정보를 포함하는 초기 ASAuthorizationAppleIDCredential을 안전하게 캐싱하는 것이 권장됩니다.
그런데 궁금한 점이 하나 있습니다. 다른 웹사이트에서 Sign In with Apple을 사용하는 사례를 본 적이 있으신가요? 저는 네이티브 앱에서만 사용해 본 것 같습니다
저에게는 이 기능이 매우 합리적으로 보입니다. 저희 iOS 앱이 discourse 웹으로 연결되는데, 앱의 다른 기능들은 로그인 없이도 사용 가능하기 때문입니다.
대부분의 사용자가 이미 해당 기기에서 로그인되어 있고, 인앱 결제에 사용되는 Apple Pay도 동일한 계정을 사용하므로, 이 방식으로 로그인하는 것은 사용자에게 매우 편리합니다.
개인적으로 Apple DTS에 이 문제에 대해 문의하여 그들이 제안하는 우회 방법을 확인하고, 또한 이것이 문제를 일으키고 있다는 피드백을 전달하는 것이 여전히 의미 있다고 생각합니다. (불행히도 저는 이 부분에 대해 충분히 지식이 없어서 그들과 직접 대화를 나눌 수 없습니다.)
Kayak과 Wordpress는 Apple의 권장 사항에 따라 첫 번째 인증 시도에서 사용자 정보를 캐싱하고 있을 것으로 추정됩니다.
우리가 채택해야 할 접근 방식이 아마도 이 방식일 것 같지만, 특히 견고하지는 않습니다(예: 첫 번째 시도 중 네트워크 연결이 끊기거나, Discourse가 백업에서 복원되거나, 사용자가 Apple 이메일 주소를 변경하는 경우). 그리고 제 생각에는 프라이버시 측면에서도 약간 나쁜 면이 있습니다(아직 가입하지도 않은 사용자의 이메일 주소를 저장해야 하니까요!).
플러그인을 최신 상태로 업데이트하여 테스트할 수 있도록 내 목록에 추가할게요. 잘 작동하면 코어에 비교적 쉽게 이식할 수 있습니다.
모든 인증 과정에서 이메일 주소가 정상적으로 표시되고 있습니다.