Removing group from the client token

Ask the Community

A change in the Cord authentication model


On 19 December, 2023 the requirement to sign a client authentication token with a group_id (formerly known as org_id) was dropped.

As a reminder, in Cord:

  • a group is a list of users
  • users may belong to multiple groups
  • when you create a thread you specify which group it should be visible to

What's the change? #

Previously a user was only able to see messages in the scope of the group_id set in their token when they logged into a Cord session. To see messages from another of their groups, they would need to be logged out and logged in again with a different token.

Now when generating a client token we recommend omitting the group_id, which will mean a user will be able to load messages from any/all of their groups in the same session.

Do I need to do anything differently as a result of this new approach? #

A consequence of this change is that some UI components and client API methods will now need to be given a groupID, depending on the circumstances. If a resource which belongs to a group is being created, it will need a groupID prop passed in.

Take the example of a Thread UI component. If it is given a threadID attribute set to the value of an existing thread, that existing thread will be loaded and so the groupID does not need to be specified as it already belongs to a group.

However, if a Thread component for a new threadID is being rendered and a message is sent from that component, it will create a new thread. In this case, groupIDwill be needed because it is a new write and Cord needs to know which group it should belong to.

An API method like the Observe Group Members method previously fetched members of the group in the token. When this is not there, it will need to be passed a groupID to know which members to fetch.

Can client tokens still be signed in the old way? #

Yes. The old model, where developers signed a client auth token with thegroup_id or org_id field, and did not specifygroupID as an argument to UI elements or client API methods will continue to be supported. Adding groupID to components or API methods that require it when the token also has a group will result in an error, unless it's the same groupID as in the token.

Does this change what messages users can see? #

No. The principle that users can only access messages which belong to a group they are a member of remains unchanged. See Permissions for more information.


Not finding the answer you need? Ask our Developer Community

Ask Cordy