Social sign-in and login branding
Open Social providers in the selected workspace. Supported provider types include Google, GitHub, LinkedIn and Facebook. Your plan must allow social providers and have capacity for another configuration.
First complete a basic hosted-login test. Adding Google or another provider also requires access to that provider's developer console. A personal Google/GitHub account alone does not supply the client ID and secret; an administrator must register the OAuth application there.
- Create an OAuth application in the provider's developer console.
- Add its provider-issued client ID and secret to the SyAuth provider configuration, together with the name and provider type.
- Register the matching SyAuth application callback with that provider:
https://api.syauth.com/e/v1/oauth/PROVIDER/callback/, replacingPROVIDERwithgoogle,github,linkedinorfacebook. - Enable social-login display in the application's branding and test from your application's hosted login flow.
The provider-to-SyAuth callback differs from your own application's redirect URI. Keep both registrations correct. A social button on the SyAuth dashboard login signs in your developer account; it is separate from sign-in to your application.
For example, when adding Google to an app running at http://127.0.0.1:8080:
| Value | Where to configure it |
|---|---|
https://api.syauth.com/e/v1/oauth/google/callback/ | Register this as an authorized redirect URI in Google's OAuth application |
| Google's client ID and client secret | Copy these from Google's developer console into the Google provider configuration in SyAuth |
http://127.0.0.1:8080/callback | Register this on your application's OAuth client in SyAuth, replacing it if your app uses a different callback |
Your SyAuth OAuth client_id | Use this in your app's hosted sign-in request, even when the user chooses Google |
The provider-issued client ID and the SyAuth client ID identify different applications. Start the test from your app's authorization URL, choose the social provider on hosted login, and confirm that the browser returns to your app's callback.
You can also start from the no-app test receiver's URL. The expected browser journey is SyAuth login → provider sign-in/approval if needed → SyAuth consent if needed → your callback. Save the provider settings before starting a new test.
| Where the test stops | What to check |
|---|---|
| No social button on hosted login | The provider is active in the intended workspace and social-login display is enabled for this client's branding |
| The provider rejects its redirect URL | Register the provider-to-SyAuth callback in the provider console, including its trailing slash |
| Login reaches your local callback but fails there | Check the app's saved attempt or use the manual receiver; changing provider credentials does not create the local callback |
Branding
Open an application's branding settings to set company name, logo, theme, colors, social-login visibility and legal links. Branding belongs to the OAuth client. The public branding/provider endpoints let hosted login obtain these settings before the user signs in.
Save the branding settings, then start a fresh authorization request for that same client ID and inspect the hosted login page. That page is where you check the logo, colors and provider display. If you still see another application's branding, check which client ID the login URL uses before changing the template again.
Check the branded page with your real callback and test account. Keep provider secrets out of browser bundles, logs and public repositories. See provider operations and branding operations.