OAuth 2.0과 소셜 로그인이란?

OAuth 2.0은 앱이 다른 서비스의 사용자 계정에 접근할 수 있게 하는 인가 표준이며, 소셜 로그인은 그 위에 로그인을 구축한 것입니다. 둘은 보통 따로 설명되고, 바로 그 때문에 혼동이 사라지지 않습니다. RFC 6749는 배관, 즉 비밀번호를 공유하지 않는 위임된 범위 지정 접근을 정의하고, OpenID Connect는 그 위에 신원 계층을 더하며, ”…로 로그인” 버튼은 이 둘 위에서 동작하는 제품 기능입니다.

핵심 요약

인가 코드 흐름, 단계별로

모든 동의 화면 뒤에서 일어나는 리디렉션 절차를, 중요한 파라미터와 함께 보면 다음과 같습니다:

1  앱 → 제공업체      /authorize?client_id=…&redirect_uri=…&scope=profile
                      &state=af3G…            ← CSRF 방어, 돌아올 때 확인
                      &code_challenge=hK9…    ← PKCE: 새로 만든 비밀 값의 해시

2  사용자 ↔ 제공업체  제공업체 쪽에서 로그인(비밀번호는 앱에 닿지 않음), 동의

3  제공업체 → 앱      redirect_uri?code=SplxlO…&state=af3G…   ← 일회용 코드

4  앱 → 제공업체      POST /token  { code, code_verifier }    ← PKCE 증명
   제공업체 → 앱      { access_token, refresh_token, id_token }

5  앱 → API           Authorization: Bearer <access_token>

백엔드가 이 흐름을 감쌀 때의 모습입니다. 제공업체의 토큰이 들어가고, 검증된 세션이 나옵니다:

// JavaScript / Node.js — Back4app JS SDK
// Social login: the provider's tokens become a user session
const user = await Parse.User.logInWith('apple', {
  authData: { id: appleUserId, token: identityToken },
});
// First login creates the user; later logins match — session token issued

// Account linking: attach a second provider to the same user
await user.linkWith('facebook', { authData: fbAuthData });

// Flutter / Dart — Back4app Flutter SDK
// Social login: the provider's tokens become a user session
final user = ParseUser.forQuery();
final response = await user.loginWith(
  'apple',
  apple(identityToken, appleUserId),
);
// First login creates the user; later logins match — session token issued

// Account linking: attach a second provider to the same user
await user.linkWith('facebook', facebook(token, fbUserId, expiresAt));

// iOS / Swift — Back4app Swift SDK
// Social login: the provider's tokens become a user session
let user = try await User.apple.login(
    user: appleUserId,
    identityToken: identityTokenData
)
// First login creates the user; later logins match — session token issued

// Account linking: attach a second provider to the same user
try await user.facebook.link(userId: fbUserId, accessToken: fbAccessToken)

// Android / Kotlin — Back4app Android SDK
// Social login: the provider's tokens become a user session
val authData = mapOf("id" to appleUserId, "token" to identityToken)
ParseUser.logInWithInBackground("apple", authData).continueWith { task ->
    val user = task.result
    // First login creates the user; later logins match — session token issued

    // Account linking: attach a second provider to the same user
    user.linkWithInBackground("facebook", fbAuthData)
}

네 가지 역할

그랜트 유형: 흐름 선택과 OAuth 2.1의 변경 사항

OAuth 2.1은 혁명이 아니라 통합입니다. 위의 지원 중단에 더해 리디렉션 URI의 정확한 일치와 쿼리 문자열 속 베어러 토큰 금지가 들어갔습니다. 10년 동안 쌓인 보안 교훈을 하나의 문서로 다시 묶은 것입니다. 개념 설명 자료의 상당수는 아직 이를 따라잡지 못했으며, 몇몇은 여전히 암시적 흐름을 아무 경고 없이 가르칩니다.

OAuth vs. OpenID Connect: 인가 vs. 인증

누구나 반복하는 한 줄, “OAuth는 인증이 아닙니다”에는 그 메커니즘에 대한 설명이 뒤따라야 합니다. 단순하게 구현한 로그인을 공격에 취약하게 만드는 것이 바로 그 메커니즘이기 때문입니다:

“액세스 토큰만으로 하는 로그인”이 실패하는 이유는 액세스 토큰이 접속 중인 사람이 아니라 권한에 대한 양도 가능한 증거이기 때문입니다. 자기 목적으로 토큰을 얻은 악성 앱은 그 토큰을 재전송해 다른 곳에서 사용자를 사칭할 수 있습니다. OpenID Connect는 정확히 그 틈을 막기 위해 존재합니다. 흐름은 같고, 여기에 앱에 암호학적으로 묶인 신원 단언이 더해집니다.

소셜 로그인: 배관 위에 얹힌 버튼

소셜 로그인은 UX로 포장된 OIDC입니다. 제공업체가 인증하고, 앱은 검증된 클레임을 받아 계정을 생성하거나 매칭합니다. 저장할 비밀번호도, 직접 운영할 재설정 흐름도 없으며, 제공업체의 MFA는 추가 비용 없이 따라옵니다. 제품 측면의 트레이드오프는 정직한 숫자로 다룰 필요가 있습니다. 가입률이 20–50% 오른다는 주장은 벤더 사이에 떠도는 이야기에 가깝고, 통제된 실험에서는 3%에 가까운 수치가 측정되었습니다. 그래도 오늘날 소비자 로그인의 약 3분의 1이 소셜 방식으로 이루어지므로, 사용자가 이 선택지를 원한다는 점은 분명합니다. 실제로 전환율을 움직이는 관행은 다음과 같습니다. 사용자층이 실제로 쓰는 두세 개의 제공업체만 제공하고(버튼을 줄줄이 늘어놓은 “NASCAR 그리드”는 측정 가능한 수준으로 역효과를 냅니다), 이메일 대안을 항상 남겨 두며, OAuth 리디렉션이 앱 내 웹뷰 안에서는 깨진다는 사실을 알아 두는 것입니다. 이는 모바일 가입 실패의 실제 원인 가운데 하나입니다. 제공업체별 사실 두 가지는 이름을 밝혀 둘 만큼 중요합니다. Sign in with Apple은 비공개 릴레이 주소(…@privaterelay.appleid.com)를 발급하므로, 이메일 기준의 계정 연결과 메일링 리스트는 불투명한 별칭을 예상해야 합니다. 그리고 Apple의 App Store 규정은 서드파티 로그인을 제공하는 앱이 개인정보를 보호하는 로그인 옵션도 함께 제공하도록 요구합니다.

계정 연결과 이메일 함정

같은 사람이 두 제공업체를 통해 들어오고, 두 곳 모두 [email protected]을 보고합니다. 고전적인 취약점을 막는 규칙은 이것입니다. 신원의 기준은 제공업체의 안정적인 sub 식별자여야 하며, 결코 이메일만으로 식별해서는 안 됩니다. 이메일은 바뀌고, 재활용되며, 가장 위험하게도 항상 검증된 것은 아닙니다. 2023년에 드러난 한 취약점 유형은 주요 제공업체 토큰에 담긴 검증되지 않은 이메일 클레임을 신뢰한 앱들이, 자신의 제공업체 계정에 그 이메일을 설정할 수 있는 누구에게나 계정 탈취를 허용한다는 사실을 보여 주었습니다. 자동 연결은 제공업체가 검증되었다고 보증한 이메일에만 적용하고, 그 밖의 경우에는 사용자에게 명시적인 연결을 요청해야 합니다. 그리고 이탈 상황에도 대비해야 합니다. 제공업체 계정이 잠긴 사용자는(예고 없이 일어나는 일입니다) 두 번째로 연결된 방법이 없다면 그 하위의 모든 앱을 잃습니다. “사용자당 로그인 방법 하나”가 단순함의 탈을 쓴 지원 티켓 생성기인 이유입니다.

일반적인 사용 사례

• 소비자 앱 로그인 – 대표적인 소셜 로그인입니다. 마찰이 적고, MFA를 물려받으며, 유출될 비밀번호 데이터베이스가 없습니다.
• 서드파티 API 접근 – OAuth 본래의 용도입니다. 일정 관리 앱이 비밀번호 없이 사용자의 캘린더를 읽는 경우입니다.
• 머신 간 인증 – 서비스 사이의 클라이언트 자격 증명으로, 사용자는 전혀 개입하지 않습니다.
• 다중 제공업체 신원 – 하나의 계정에 여러 로그인 방법을 연결하고, 사용자별 연결 해제와 복구를 지원합니다.
• 엔터프라이즈 SSO 연계 – 같은 OIDC 패턴을 소셜 제공업체 대신 임직원용 ID 공급자에 적용합니다.

소셜 로그인을 제공해야 할까? 결정 매트릭스

한계와 트레이드오프

• 제공업체의 결정을 물려받습니다. 동의 화면, 세션 수명, 계정 복구, 지원 중단은 앱의 일정이 아니라 제공업체의 일정에 따라 일어납니다.
• 집중 위험은 실재합니다. 제공업체의 장애나 계정 잠금은 곧 앱의 로그인 장애입니다. 연결된 대체 방법은 있으면 좋은 부가 기능이 아니라 완화책입니다.
• OAuth의 유연성은 역사적인 약점입니다. 선택지가 많은 프레임워크는 안전하지 않은 조합을 부릅니다. 2.1이 존재하는 이유는 암시적 흐름, 와일드카드 리디렉션, 회전하지 않는 리프레시 토큰이 계속 배포되었기 때문입니다.
• 리디렉션 흐름에는 날카로운 모서리가 있습니다. state(CSRF), 정확한 리디렉션 URI(오픈 리디렉트와 코드 탈취), PKCE(가로채기)는 각각 파라미터 하나만 빠져도 사고로 이어집니다.
• 소셜 클레임은 최소한의 출발점일 뿐 완전한 프로필이 아닙니다. 받는 것은 주체, 이메일, 이름 정도이며, 그 이상의 속성에는 여전히 자체 온보딩이 필요합니다. 프라이버시 릴레이 때문에 이메일조차 별칭일 수 있습니다.

Back4app에서의 OAuth와 소셜 로그인

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 위의 흐름은 코드 탭 안으로 압축됩니다. 클라이언트가 제공업체의 토큰을 네이티브 방식으로 받아 logInWith에 넘기면, Back4app의 인증 어댑터가 서버 측에서 제공업체를 통해 토큰을 검증한 뒤 User를 생성하거나 매칭합니다. 제공업체 신원은 안정적인 주체 ID를 키로 하는 제공업체별 authData 블록에 저장되므로, 계정 연결 규칙이 구조적으로 강제됩니다. linkWith는 같은 사용자에게 다른 제공업체(또는 이메일 자격 증명)를 추가로 연결하여 잠금 문제를 호출 한 번으로 해결합니다. 앱이 받는 세션 토큰은 이후 REST, GraphQL, Live Query API 전반에서 동작하며, 그 토큰이 무엇에 접근할 수 있는지는 ACL과 클래스 수준 권한이 결정합니다. 리디렉션 절차, 토큰 검증, 계정 연결의 예외 상황은 플랫폼의 기본 동작으로 제공되므로, 대시보드에서 제공업체를 설정하고 버튼을 배포하기만 하면 됩니다.