Overview & Concepts
Authentication in social.plus
social.plus uses a dual authentication approach to ensure both application security and user verification:API Key
Purpose: Identifies your application to social.plus servers
Scope: Application-level authentication
Usage: Required for SDK initialization
Security: Keep secure, never expose in client code
Scope: Application-level authentication
Usage: Required for SDK initialization
Security: Keep secure, never expose in client code
Auth Token
Purpose: Server-to-server verification that the user is validated by your backend
Scope: User-level authentication with your system
Usage: Optional for development, required for production
Security: Generated by your backend, proves user is legitimate
Scope: User-level authentication with your system
Usage: Optional for development, required for production
Security: Generated by your backend, proves user is legitimate
How Auth Tokens Work
Auth tokens enable server-to-server communication between social.plus and your backend:User Authentication
Your app authenticates the user with your own authentication system (login, OAuth, etc.)
Backend Token Generation
Your backend server generates an auth token for the verified user and sends it to your app. Learn how to implement this →
social.plus Verification
When your app logs into social.plus, the auth token proves to social.plus that your backend has verified this user
Why Auth Tokens? This approach ensures that only users who have been properly authenticated by your backend can access social.plus features, maintaining security and preventing unauthorized access.
When Do You Need Each?
- Production
- Development
Quick Start (Basic Authentication)
Step 1: Initialize the SDK
Start by setting up the social.plus client with your API key:Step 2: Login User
Authenticate users to access social.plus features:Step 3: Check Authentication Status
Verify if a user is currently logged in:Step 4: Logout
End the user session: For an extra layer of security, which ensures accessToken revocation prior to performing logout(). Should the SDK fail to revoke the accessToken, the SDK will not proceed to logout and will throw an exception to notify the failure.Understanding Session States
Session states indicate what’s happening with user authentication. social.plus SDK automatically manages these states according to the flow shown in the diagram below:notLoggedIn
Ready for login - user needs to authenticate
Entry points: App start (no session), logout, login failure
Entry points: App start (no session), logout, login failure
establishing
Login in progress - authentication being processed
Entry point: When login() is called from notLoggedIn state
Entry point: When login() is called from notLoggedIn state
established
Fully authenticated - SDK ready, all features available
Entry points: Successful login, successful token renewal
Entry points: Successful login, successful token renewal
tokenExpired
Token renewal needed - automatic renewal attempted
Entry point: When auth token expires during established state
Entry point: When auth token expires during established state
terminated
Session forcibly ended - user banned or deleted
Entry points: User banned/deleted from established or tokenExpired states
Entry points: User banned/deleted from established or tokenExpired states
Session Flow
Understanding the complete session state flow helps you build responsive apps:SDK Initialization
App starts: Always begins in the
start state, then immediately moves to:- No saved session: Moves to
notLoggedInstate - Has saved session: Moves to
establishedstate (if session valid)
Login Process
User attempts login:
notLoggedIn→establishing(login in progress)- Login succeeds:
establishing→established - Login fails:
establishing→notLoggedIn
Active Session Management
During active use in established state:- Token expires:
established→tokenExpired - Token renewed successfully:
tokenExpired→established - User banned/deleted:
established→terminated - Manual logout:
established→notLoggedIn
Token Expiration Handling
When in tokenExpired state:- Auto-renewal succeeds: Returns to
establishedstate - Auto-renewal fails: User may need to re-authenticate
- User banned during renewal: Moves to
terminatedstate - Manual logout: Moves to
notLoggedInstate
Session state diagram image temporarily removed while the asset is unavailable. The textual flow description above preserves the full logic.
Observing Session State
Monitor session state changes to handle authentication in your app:- iOS
- Android
- TypesScript
- Flutter
Advanced Session Management
For production apps, you’ll need sophisticated session handling with automatic token refresh:Session Handlers for Token Refresh
Session handlers automatically manage token lifecycle:- iOS
- Android
- TypesScript
- Flutter
Alternative: Login with Access Token
By default, social.plus SDK handles access token management for you — you provide auserId and an optional authToken, and the SDK takes care of obtaining and refreshing access tokens behind the scenes.
Login with Access Token is an alternative authentication method for customers who want to manage the entire token lifecycle themselves. Instead of letting the SDK obtain tokens, your backend issues a JWT access token directly, and your app passes it to the SDK.
Most developers should use the default login flow described in the Quick Start section above. Only use this approach if you have a specific need listed below.
When to Use This
SSO Integration
Your app already has a centralized authentication system and you want social.plus sessions to be issued as part of that flow — no extra network hop from the client.
Reduce Client-Side Dependencies
You want to eliminate the client-to-social.plus token exchange during login so that social.plus API availability does not block your app’s core login experience.
Default Login vs. Access Token Login
| Default Login | Login with Access Token | |
|---|---|---|
| SDK method | login(userId, authToken) | loginWithAccessToken(accessToken) |
| Who obtains the access token? | The SDK handles it automatically | Your backend issues a JWT and your app passes it to the SDK |
| Token renewal | Session handler (sessionWillRenewAccessToken) | Access token handler (onTokenRenew) |
| Best for | Most integrations | SSO, custom auth backends, decoupled architectures |
| Client-to-social.plus call during login? | Yes — SDK exchanges credentials for a token | No — token is pre-issued by your backend |
How It Works
Implementation
Integration requires three steps: implement a token handler, register it, then login.Implement an Access Token Handler
Create a handler that the SDK will call whenever the token needs renewal. Your handler should request a fresh JWT from your backend.
Register the Handler
Call
setAccessTokenHandler() before logging in. This tells the SDK how to obtain a new token when the current one expires.- iOS
- Android
- TypeScript
Security Best Practices
Production Token Management
Backend Token Generation
Backend Token Generation
Auth tokens must be generated by your secure backend to establish server-to-server trust with social.plus.Refer to the general API Reference introduction until the dedicated authentication endpoint page is published.Why this approach?
- Your backend vouches for the user’s authenticity to social.plus
- social.plus trusts users who have valid tokens from your verified backend
- Prevents unauthorized access to social.plus features
- Maintains security boundary between your auth system and social.plus
Authentication Best Practices
Do's ✅
Do's ✅
- Monitor session state changes in your app’s main navigation logic
- Handle token expiration gracefully with automatic refresh
- Provide clear feedback to users during state transitions
- Clean up subscriptions when components unmount
- Use secure logout when security is critical
- Store tokens securely using platform-specific secure storage
Don'ts ❌
Don'ts ❌
- Don’t ignore session state changes - they indicate important authentication events
- Don’t store sensitive data when user is not authenticated
- Don’t make API calls before reaching
establishedstate Don't forget to handle the terminated state- users may be banned- Don’t expose API keys in client-side code
- Don’t use plain text storage for auth tokens
Troubleshooting
Session state stuck in 'establishing'
Session state stuck in 'establishing'
Symptoms: Login never completes, app shows loading indefinitelySolutions:
- Check your API key and network connection
- Verify authentication token is valid
- Ensure you’re using the correct region
- Check for console errors or network timeouts
Frequent token expiration
Frequent token expiration
Symptoms: Users get logged out too oftenSolutions:
- Check your backend token expiration settings
- Verify session handler implementation
- Ensure token refresh logic works correctly
- Consider longer token expiration for better UX
Session handler not called
Session handler not called
Symptoms: Tokens don’t refresh automaticallySolutions:
- Verify you’re passing the session handler during login
- Check that your backend token has appropriate expiration
- Ensure session handler implementation handles errors
- Test with shorter token expiration for debugging
App crashes on session state change
App crashes on session state change
Symptoms: App crashes when authentication state changesSolutions:
- Ensure UI updates happen on the main thread
- Handle all possible session states in switch statements
- Add proper null checks and error handling
- Clean up observers when components unmount
loginWithAccessToken fails immediately
loginWithAccessToken fails immediately
Symptoms: Calling
loginWithAccessToken() throws an error before reaching the serverSolutions:- Ensure you called
setAccessTokenHandler()beforeloginWithAccessToken()— the handler must be registered first - Verify your JWT is well-formed (valid JSON Web Token structure)
- Check that the JWT contains the required
userIdclaim - Confirm your backend is signing the token with the key configured in the social.plus console
Access token handler (onTokenRenew) not called
Access token handler (onTokenRenew) not called
Symptoms: Token expires but the SDK does not invoke your
onTokenRenew handlerSolutions:- Verify you logged in via
loginWithAccessToken()— the handler is only invoked for access-token sessions, not defaultlogin()sessions - Check that the handler was registered with
setAccessTokenHandler()before login - Ensure the user is not globally banned — the SDK skips handler invocation for banned users
Next Steps
User Management
Learn about user profiles and management
Social Module Overview
Explore social capabilities structure
Chat Module Overview
Add real-time messaging
Console Overview
Configure security and settings in the Console