[CS] 애플 로그인을 구현할 때 왜 서버가 필요할까?

개요

최근 스위프트 오픈 카톡방에서 '애플 로그인을 구현할때 서버가 필요한가요?' 라는 질문을 봤습니다.

사실 이 질문은 단순히 기능 구현의 문제가 아니라, 소셜 로그인 방식의 작동 원리와 보안 구조를 제대로 이해하고 있는지를 보여주는 중요한 질문입니다.

 

소셜 로그인은 OAuth2.0 으로 지원된다.

소셜 로그인(Google, naver, kakao 등)은 보통 OAuth 2.0으로 제공됩니다.

OAuth는 무엇일까요?

OAuth는 사용자가 아이디와 비밀번호를 직접 입력하지 않고도, 제 3의 앱이나 서비스가 권한 있는 방식으로 사용자 정보를 얻을 수 있도록 허용하는 표준 프로토콜 입니다.

예를 들어 우리가 어떤 앱에서 Apple로 로그인을 누르면 Apple은 인증을 수행한 뒤 Auth를 사용하는 서비스(이하 '앱')에 인증 결과 토큰(JWT 형식)을 전달합니다.
앱은 이 토큰을 바탕으로 사용자의 로그인을 처리합니다. 사용자의 비밀번호는 우리 앱엔 직접적으로 전달되지 않습니다.

 

왜 OAuth 같은 방식이 필요할까요?

우리는 날이 갈수록 보안에 대한 인식이 점차 강화되고 있습니다. 

이 과정에서 일반적인 사이드프로젝트나, 소규모 회사등의 서비스에선 유저의 정보를 직접 저장하고 관리하는것이 법적/ 기술적으로 부담이 될 수 있는 실정입니다.

앞서 얘기한것 처럼 사용자의 예민한 정보를 우리 앱에 직접적으로 저장하지 않기때문에, 이러한 보안 리스크가 훨씬 적어지고, 로그인 기능을 빠르게 추가할수도 있겠죠

 

더붙여 사용자 입장에서도 장점이 있습니다.

새로운 계정을 만들 필요가 없고,

이미 익숙한 플랫폼 계정으로 로그인을 할 수 있으니 새로운 서비스 사용에 대한 부담이 줄어들겠죠

그럼 OAuth는 어떤 방식으로 동작할까요?

비유하자면 토큰 이라는 임시 열쇠를 통해 간접적으로 권한을 받는겁니다.

간단히 말해, 소셜 로그인에서 앱이 사용자 정보를 직접 얻는 게 아니라
토큰(Token)이라는 임시 열쇠를 통해 간접적으로 권한을 받습니다.

🔑 비유하자면:

앱은 사용자에게 직접 집 열쇠를 받는 게 아니라,
사용자 본인이 인증기관에서 발급받은 '임시' 열쇠를 앱에게 넘기는 구조입니다.
앱은 이 열쇠(Access Token)를 갖고 사용자 정보를 제한적으로 열람할 수 있습니다.

 

이 구조 덕분에 앱이 사용자 비밀번호를 다룰 일이 없어지고,
토큰의 범위와 유효시간이 제한되므로 보안적으로도 안전합니다.

 

그럼 OAuth는 보안적으로 더할 나위 없이 아주 훌륭할까요?

OAuth는 권한 위임만을 처리합니다. (이를 Delegated Authorization라고 표현) 

즉 누간가의 정보를 접근해도 된다 정도의 허락을 주는것이지 

'이 사용자가 진짜 누구임?' 까지의 문제는 해결해주지 않습니다.

이 과정에서 등장하게 되는것이 OpenID Connect (OIDC)입니다

 

애플 로그인은 OIDC 기반으로 작동한다

앞서 OAuth는 열쇠를 제공받는다고 했습니다.

이 방식은 어떻게 보면 열쇠만 있으면 내가 그 사람이 누릴 수 있는 혜택을 똑같이 누릴 수 있다는 이야기가 됩니다.

여기서 OIDC가 조금 더 강화된 보안을 제공합니다. OIDC가 뭘까요?

OIDC는 Auth 2.0 프로토콜을 기반으로 한 인증 프로토콜입니다. 

OIDC는 Auth 2.0 + ID 확인 인증 레이어를 추가한 방식입니다.

더욱 강화된 보안성을 제공해줄 수 있겠죠

앞서 열쇠에 비유했으니 이건 열쇠와 더불어 신분증 인증까지 하는 개념이라고 할 수 있을것 같습니다

개념적인 부분 보다도 이번 포스팅에서 결론적으로 얘기하고 싶은 내용은 
애플로그인은 OIDC 방식을 채택하고 있으며 이는 Auth 2.0 기반으로 동작한다 입니다.

 

그래서 서버가 왜 필요하다고?

'애플로그인 구현에 서버가 필요한가요?'라는 질문은 곧 

OAuth 2.0, OIDC 구현에 왜 서버가 필요한가요? 랑 같은 내용으로 귀결됩니다.

 

 1. 민감 정보 보호 (Client Secret & 토큰)

OAuth 2.0에서는 클라이언트 앱이 서비스에 접근할 수 있도록 client_id와 client_secret이라는 고유한 정보가 발급됩니다.

이 중 client_secret은 절대로 클라이언트 앱 내부에 포함되어서는 안 됩니다.
누구나 디컴파일하거나 네트워크 트래픽을 분석해 시크릿을 탈취할 수 있기 때문이죠.
따라서, 이 정보를 안전하게 저장하고 사용하는 역할은 서버가 전담해야 합니다.

 

2. Authorization Code 교환 단계

많이 사용하는 인증 방식인 Authorization Code Flow는 두 단계로 나뉩니다:

1. 사용자 인증 → Authorization Code 획득
2. Authorization Code → Access Token 교환

두 번째 단계에서 client_secret이 필요하기 때문에, 이 교환 작업은 서버에서 안전하게 처리되어야 합니다.

클라이언트에서 처리하면 인증 정보가 유출될 가능성이 생기므로 보안적으로 권장되지 않습니다.

 

3. 사용자 정보 요청과 세션 유지

OAuth로 인증이 완료된 후에도 우리는 사용자의 정보(예: 이메일, 프로필 등)를 불러오거나, 앱 내에서 로그인 상태를 유지해야 합니다. 이때 서버는:

• Access Token을 이용해 사용자 정보를 요청
• 사용자 세션을 유지 (쿠키 or JWT 기반)
• 추가적인 사용자 데이터와 연결 (DB)

하는 등의 역할을 수행합니다. 클라이언트만으로는 이 흐름을 안전하게 유지하기 어렵습니다.

 

마치며

정말 쉽게 한줄로 표현하면 'OIDC, OAtuh 가 그걸 요구하니까' 라고 대답할 수 있겠지만,

한 발자국 더 들어가 그니까 그걸 왜 요구하는데? 까지 알아봤습니다.

이 외에도 OAuth, OIDC 구현에 서버가 필요한 이유는 이 외에도 많이 있겠지만  큰 내용들을 정리해봤습니다.

 

어쩌면 민감 정보를 클라이언트가 아닌 서버 사이드에서 처리해야 하는 보안원칙과 대동소이 하다고 할 수  있을것 같네요

이번 프로젝트에 소셜로그인은 포함되지 않았지만 추후 진행하게 된다면 더 수월하게 진행할 수 있을거 같네요.