User Authentication

Sendbird provides a token based approach for authenticating client end users of Sendbird’s services, including SDKs and UIKits. Depending on the Sendbird Application’s Access token permission settings it is possible to determine end user access.

To view the image in full screen, click on the

Three options are provided for access: Deny login, Read only, and Read & Write. A detailed description of each option is as follows.

• Deny login: Users must have a valid authentication method to connect/authenticate.
• Read only: Users can connect/authenticate and access information of users without authentication.
• Read write: Users can connect/authenticate, read and write account information without a token.
  • Note #1: New users are automatically created if a non-existing user_id is provided during connection/authentication.
  • Note #2: If a user is issued with a session token at any point after creation, they will always need a token to authenticate regardless of the Access token permission settings.

By default, all Sendbird applications are set to "Read & Write". However, the “Read & Write” option is recommended only for when getting started trying out Sendbird, and not for production. Depending on the settings, users can access their Sendbird user profile without authentication. If you issue a session or access token to a user, the user will always be required to provide a session or access token to connect/authenticate to Sendbird regardless of your application security settings. “Deny login” is recommended for production as it prevents users without a token from accessing your application and also prevents the automatic creation of users that do not exist.

If you set the option to "Deny login" to allow only authenticated users to log in, users must provide a valid Sendbird access or session token during the login process. Once a user successfully authenticates in your backend application, a token must be issued specifically for logging into Sendbird. It is critical that this token is generated exclusively for the authenticated user and is never mistakenly assigned to someone else. Additionally, when issuing tokens, remember that they are intended solely for the current user.

If the Access token permissions are misconfigured, users might unknowingly be logged into someone else's account. Consequently, unauthorized individuals could gain access to private conversations, view chat histories, and collect personal information. This data may then be exploited to send malicious links or fraudulent messages—either by impersonating the legitimate user or by launching targeted spam and phishing attacks—which could ultimately lead to identity theft or financial fraud.

If the token setting is set unintentionally, it can result in users being logged into someone else's account without their knowledge. This means that an unauthorized individual could access private and sensitive conversations, read existing chats, and gather personal information. They could then use this data to send malicious links or fraudulent messages, either posing as the legitimate user or exploiting the information for targeted spam and phishing attacks, potentially leading to identity theft or financial fraud.

If you need a one-time authentication method to improve the security level, you can use a session token. Please refer to the Session token guide for details on issuing and using session tokens.