Social Login Registration and Setup Guide

The keys, files and registered settings to hand over for Kakao, NAVER, Google and Apple login, with registration steps.

1. Account registration and management

Social login requires registering your service with each provider and connecting its credentials. Adding a button alone does not complete setup.

Use a personal or company-managed service account for registration, identity and business checks, agreements and any payments. Retain account ownership for ongoing service management.

Register the addresses and settings supplied by your developer, then share the issued credentials and configuration results. Account passwords, verification codes and recovery codes are not handover items.

2. Prepare these before registration

Basic information: service name, logo, company and representative details, contact email and identity verification. Prepare supporting documents when business or organization verification is required.
Ask your developer: development and production site addresses, each provider’s exact Redirect URI / Callback URL / Return URL, and the user information your service needs.
Agree together: service introduction, privacy policy and terms URLs, sign-in, registration and account-deletion flows, and screenshots for review.
For mobile apps: get Android package names and signing fingerprints/key hashes, plus iOS Bundle IDs, from your developer. Web credentials do not complete native app registration.

3. Credentials at a glance

For a web server authorization-code flow. Kakao requires Client Secret when enabled; Google browser-only sign-in needs only Client ID. SDK and mobile additions are listed below.
Provider	Issue or confirm and hand over	Confirm before launch
Kakao	REST API key and Client Secret when enabled. JavaScript/native app keys only for the corresponding SDK.	Login enabled, consent items and redirect URI; permissions and reviews for additional user data.
NAVER	Client ID and Client Secret.	Service URL, Callback URL, use of user data and NAVER Login review approval.
Google	OAuth Client ID and Client Secret for a web server authorization-code flow. Browser-only sign-in needs only Client ID.	Consent screen, external audience and registered URLs; any scope or branding verification.
Apple	Team ID, Services ID (web Client ID), Key ID and original Sign in with Apple .p8 file. Add Bundle ID for native apps.	Developer Program membership/renewal, primary App ID association, domains, Return URL and server authentication.

4. Registration by provider

Kakao

Kakao — Open registration console

Required values for web server login

REST API key — the full value from App > Platform keys > REST API key.
Client Secret status (ON/OFF), plus the full secret when ON. New REST API keys have it ON by default.

Additional items only when applicable

For the JavaScript SDK: JavaScript key.
For Android/iOS SDKs: native app key. App ID can also be supplied as a management reference.

Settings to register and confirm

The full registered Kakao Login Redirect URI and its development/production environment.
Login enabled status, consent items and approvals. For SDKs, confirm registered domains, package name, key hashes and Bundle ID.

Registration and configuration steps

Create an app in Kakao Developers using the account for your service and enter your service and company details.
Enable Kakao Login in the app settings and agree on consent items with your developer.
Under App > Platform keys > REST API key, check the key and Client Secret and register your developer’s redirect URI. New REST API keys have Client Secret enabled by default.
For the JavaScript SDK, configure its key and SDK domains. Native apps need the package name, key hashes and Bundle ID supplied by your developer.
Check business-app conversion, business verification and additional review requirements for restricted consent items such as email. Confirm the required permissions and share the app ID and credentials.

Official documentation: Kakao Document 1 · Kakao Document 2

NAVER

NAVER — Open registration console

Required values for web server login

Client ID — the full value under My applications > your app > Overview.
Client Secret — the full secret issued for that same app.

Additional items only when applicable

For mobile apps: registered Android package name, iOS URL Scheme and other applicable platform settings.

Settings to register and confirm

Full registered service URL and Callback URL, labeled by development/production environment.
User information fields, development/production status and review results. Confirm registration of any account used for testing before approval.

Registration and configuration steps

Use a personal or company-managed service account at NAVER Developers > Application > Register application.
Select NAVER Login and request only the user information agreed with your developer.
Register the web service URL and Callback URL. Add the appropriate environment details if you also offer mobile apps.
Share the Client ID and Client Secret from My applications. Register a test account only when testing with another account before approval; console administration access is not required.
Prepare evidence of the login flow and use of requested user information with your developer. Submit for review, address feedback and confirm approval.

Official documentation: NAVER Document 1 · NAVER Document 2 · NAVER Document 3

Google

Google — Open registration console

Required values for web server login

OAuth Client ID — the full value for the relevant Web application in Google Auth Platform > Clients.
Client Secret — the secret for that server client. Do not supply it for browser-only sign-in.

Additional items only when applicable

For Android/iOS apps: OAuth Client IDs for each platform requested by your developer.
Project ID and client name are management references, not replacements for OAuth Client ID.

Settings to register and confirm

Registered Authorized redirect URIs and, for browser integration, Authorized JavaScript origins.
Development/production environment, Audience, publishing status, scopes and required verification results. Confirm test-user registration if access is restricted.

Registration and configuration steps

Create or select the service project in Google Cloud Console. You can configure it yourself and share the credentials; inviting a developer is optional.
In Google Auth Platform > Branding, configure the app name, support email, service and privacy policy URLs. Choose the audience; check external access for public customers.
In Clients, create an OAuth client. For web server login choose Web application and register the supplied Authorized redirect URIs. Confirm any browser-flow JavaScript origins.
Share the Client ID and, for server flows, Client Secret. Create separate Android/iOS clients of the types your developer requests.
Check test users and publishing status and complete any required branding or scope verification. Basic sign-in and sensitive/restricted API access have different review requirements.

Official documentation: Google Document 1 · Google Document 2 · Google Document 3

Apple

Apple — Open registration console

Required values for web server login

Team ID — the team identifier in your Developer account’s Membership details.
Services ID — the full web-login Identifier registered in Identifiers, not its display name.
Key ID — the identifier of the key created for Sign in with Apple in Keys.
Original .p8 private key file — the Sign in with Apple key matching that Key ID. Its filename or Key ID alone is insufficient.

Additional items only when applicable

For native apps such as iOS: the App ID’s Bundle ID, used as Client ID for native authentication.
You do not separately issue a client secret JWT. Your developer creates and renews it using Team ID, Client ID, Key ID and .p8.

Settings to register and confirm

The primary App ID associated with Services ID, registered domains, full Return URL and development/production environment.
Sign in with Apple enabled status and Developer Program membership status. Confirm the key is associated with the same primary App ID.

Registration and configuration steps

Prepare Apple Developer Program enrollment as an individual or organization. Check two-factor authentication, enrollment requirements and current paid membership and renewal terms.
In Certificates, Identifiers & Profiles > Identifiers, enable Sign in with Apple for a primary App ID. Web login must also be associated with an enabled primary App ID.
Register a web Services ID. Under Sign in with Apple > Configure, associate the primary App ID, domains and your developer’s Return URL.
In Keys, create a Sign in with Apple key associated with the primary App ID. Record the Key ID and download the .p8 file. Creation requires Account Holder or Admin access.
Securely hand over the Team ID, App ID, Services ID, Key ID and .p8 file. Your developer signs the server client secret and manages its expiry and renewal.

Official documentation: Apple Document 1 · Apple Document 2 · Apple Document 3 · Apple Document 4

5. Final developer handover

Share each provider’s required and applicable additional items, labeled by development/production environment. Send full credential strings and the original Apple .p8 file. A filename or screenshot with secrets hidden is not sufficient for integration.
Share Client Secrets and Apple .p8 files through an agreed secure channel, never public chats, posts or Git repositories. Kakao App ID, Google project ID and app names are management references and do not replace login credentials.
Registered site domains and callback addresses, development/production environment, and approved user information fields.
Development, testing or production status, test accounts, review results and requested changes. Screenshots with secrets hidden can help confirm settings.

Credentials issued does not mean ready to launch

Your developer connects the credentials on the server and checks sign-in, registration, returning users and account deletion. Before launch, confirm that ordinary users can sign in and required reviews and production settings are complete. Coordinate credential rotation and domain changes with your developer because they can affect existing login.

Official documentation checked November 14, 2026. Console menus and requirements can change; also consult the linked official guidance.