OAuth - Kakao vs Apple

 

누가 가입/탈퇴 절차의 책임을 지는가

사이드 프로젝트를 진행하면서 iOS는 카카오, 애플 소셜 로그인을 가져가고 있는데 이 둘의 차이점에 의해 백엔드와 길게 논의하는 시간이 있었다. 카카오는 앱에서 카카오 인증 서버에게 토큰을 발급받는데 애플은 그렇지 않아 생기는 논쟁이었다.

서버 주도의 Apple

애플 로그인의 흐름은 다음과 같다.

1. 앱에서 Apple 로그인 요청 → 사용자 동의
2. Apple이 AuthorizationCode 전달
3. 앱이 AuthorizationCode를 서버로 전달
4. 서버가 Apple API에 Authorization Code를 제출해 AccessToken & RefreshToken 발급
5. 서버에서 가입 / 로그인 처리 및 토큰 관리
6. 탈퇴할때도 서버에서 RefreshToken을 활용해 Apple API 호출

이때 AccessToken을 발급받거나, 탈퇴 처리를 할 때 서버에서만 관리하는 -그렇지 않으면 보안 이슈가 생길 수 있는- client_secret을 사용해야 한다. 책임의 주체는 서버로 토큰 발급, 갱신, 만료 관리, 가입 여부 판단 모두 서버에서 처리한다. 보안성이 높고 토큰 관리를 서버에서 온전히 책임진다는 장점이 있다.

앱 주도의 Kakao

카카오의 경우는 조금 다르다. 카카오톡 앱에서 로그인을 할 수 있도록 하려면 SDK를 사용해야 하는데, 이를 사용하면 앱이 카카오 인증 서버에서 AccessToken을 발급 받게 된다. 즉 가입/로그인 할 때의 책임이 온전히 한쪽에 있지 않고 나뉘게 되는 것이다.

1. 앱에서 Kakao SDK 호출 → 로그인 화면 표시 (앱으로)
2. 카카오 인증 서버에서 사용자 동의 → AccessToken 발급
3. 앱이 AccessToken을 서버로 전달
4. 서버가 해당 토큰을 사용해 카카오 API를 호출하거나 가입 처리

토큰 발급 / 갱신 / 만료 감지는 앱의 책임이지만, 서버 유효성 검증 / 사용자 정보 조회 / 가입 / 로그인 처리 / 서비스 내 권한 관리는 서버의 책임으로 나뉘게 된다.

서버 주도의 Kakao?

때문에 백엔드 개발자 분이 두 경우 동일하게 책임이 한쪽에 있었으면 좋겠다는 의견을 제시하셨다. 이에 동의하고 카카오에서 Authorization Code만 발급받으려 했으나 이 경우 “카카오톡 앱으로 로그인”은 할 수 없었다. 코드 → 서버 교환 단계가 SDK 밖으로 노출되지 않고 사용자 동의 후 곧바로 OAuthToken을 앱에 반환해주기 때문이었다. 우리는 앱 서비스임에도 불구하고 Authorization Code를 전달로 인해 카카오 로그인을 하려면 웹이 열려서 사용자가 직접 본인의 카카오 아이디와 비밀번호를 쳐야 하는 상황이 되었다.

결국 이 경우 사용자 경험이 좋지 않을 것 같다는 판단에 다시 원래 상태로 돌아와 카카오와 애플은 서로 다른 책임과 로직을 가지게 되었다. 더 좋은 방법이 있다면 공유해주시면 좋겠다…