Social Login best practices

Follow these recommendations to keep social sign-in reliable, secure and easy for your users.

Security

• Always serve the workspace over HTTPS. Providers require secure redirect URLs, and tokens must never travel over plain HTTP.
• Treat the Client secret like a password. Never share it, never paste it into email or chat, and store it only in the provider tab.
• Guard the Apple .p8 private key especially carefully. Apple lets you download it exactly once, and anyone holding it can impersonate your sign-in integration. Keep an offline copy in a password manager or vault, and revoke the key in the Apple Developer portal (then create a new one) if it may have leaked.
• Rotate secrets periodically and immediately if one may have been exposed. After changing a secret in the provider console, update it in NIZU — the provider status returns to Unauthorized until you save and authorize again.
• Enable only the providers you actually use. Fewer active integrations means a smaller attack surface and a cleaner sign-in page.

Configuration

• Copy the redirect URL exactly. The URL registered with the provider must match the one NIZU shows character for character, or sign-in fails.
• Confirm the status badge reads Authorized before announcing the feature. If it shows Unauthorized, the button will not appear on the sign-in page.
• For Microsoft, pick the right account scope. Choosing “any organizational directory and personal Microsoft accounts” lets both company Microsoft 365 and personal outlook / hotmail / live accounts in; pick an organization-only option if you want to restrict access to your company.
• For Apple, register the domain and return URL exactly. The Services ID configuration must list your workspace domain and the return URL NIZU shows, over HTTPS. If the token exchange fails with invalid_client, re-check the Services ID, Team ID, Key ID and .p8 key together — all four must belong to the same team.
• Test with a real account after each change — ideally in a private browser window — before relying on it in production.

Accounts and access

• Understand what happens on first sign-in. If the provider email matches an existing NIZU user, that user is logged in. If not, and client signup is allowed, a new client contact is created automatically.
• Keep user email addresses accurate in NIZU. Matching is done by email, so a team member's NIZU email must equal the address returned by their provider.
• Expect Hide My Email addresses from Apple users. People signing in with Apple may share a private relay address (ending in privaterelay.appleid.com) instead of their real one. Mail sent there is forwarded normally, but an existing user who hides their email will not match their NIZU account — ask team members and known clients to share their real email during the Apple prompt, or add the relay address to their NIZU profile.
• Use the client login / signup switches in the core settings to control whether new clients may self-register through social login.

User experience and privacy

• Tell users which providers are available so they use the same account each time and avoid creating duplicates.
• Only request the data you need. Social Login reads just the user's email and name to identify them; it does not post on their behalf.
• Document the sign-in options in your onboarding material for a smoother first experience.