Bitrix24 Integration with OAuth Providers Setup
Registration on corporate portal with login and password is a barrier. Employee forgets password, resets, forgets again. For portals with external users (clients, partners), problem is more acute: person doesn't want another account. Login via Google, Facebook or Apple ID reduces friction: user clicks button, confirms access — and they're in. In Bitrix24, this is handled by socialservices module.
socialservices Module
The socialservices module manages authentication via external OAuth providers. It comes in standard Bitrix24 delivery (both cloud and boxed). Module supports providers out of the box:
- Google — OAuth 2.0 via Google Cloud Console
- Facebook (Meta) — OAuth via Facebook for Developers
- Apple — Sign in with Apple via Apple Developer Portal
- Yandex, Mail.ru, VKontakte — for Russian-speaking audience
- Microsoft Live — OAuth via Azure App Registration
Each provider is connected separately. For each, register application with provider and get Client ID and Client Secret.
Google OAuth Setup
Connecting via Google is most common scenario. Steps:
- In Google Cloud Console create project (or use existing).
- Enable Google+ API / People API.
- In Credentials section create OAuth 2.0 Client ID. Type: Web Application.
- Specify Authorized redirect URI:
https://your-domain.bitrix24.by/bitrix/tools/oauth/google.php(for boxed) or appropriate cloud URL. - Copy Client ID and Client Secret.
- In B24: Settings → Social Services → Google — paste Client ID and Client Secret, enable authentication.
After activation, "Login via Google" button appears on B24 login page. On first login, user is offered to link Google account with existing account or create new one.
Apple Sign-In Setup
Apple requires additional steps:
- Register App ID and Services ID in Apple Developer Portal.
- Generate Private Key for authentication (key used to create Client Secret — Apple doesn't issue static secret, secret generated as JWT).
- Specify Return URL and Domain Verification — Apple verifies domain via DNS record.
Apple sends username only on first login. If data not saved first time — Apple won't provide it again. Must account for this in processing.
Token Handling and Security
During OAuth authorization, B24 receives access token and (optionally) refresh token from provider. Access token is used to request user profile (email, name, avatar). After getting profile, B24 creates session — further work via internal B24 authorization, OAuth token no longer used.
Security recommendations:
- Limit list of providers — don't enable all. For corporate portal, Google and Microsoft enough.
- Forbid account auto-creation — if portal is closed, new user via OAuth should not get access automatically. Configured in socialservices module.
-
Domain binding — allow OAuth login only for email from corporate domain (
@company.com).
Account Linking
If user already has account in B24, on first OAuth login system offers to link accounts. After linking, user can login both via login/password and via provider. One user can bind multiple providers simultaneously.
Managing bindings — in user profile: Profile → Social Network Binding.
What We Configure
- Register OAuth applications at providers (Google, Facebook, Apple)
- Connect socialservices module and enter Client ID / Client Secret
- Configure redirect URI and domain verification
- Policy for account auto-creation and binding to existing users
- Restrict OAuth login by email domain
- Test authentication flow for each provider