This page describes the best practices developers should observe when sharing access to controlled content. Updates to permissions can be done either before a collaborative activity starts or while it's ongoing.
It's strongly recommended to implement a method that creates the least amount of user friction or disruption. Developers should maintain a balance between the constraints in the app's access control model and security requirements, and any user disruption.
The following are several ways to provide access to collaborative activities.
Grant temporary access token (recommended)
A temporary (expiring) access token provides a user's access and security credentials that are valid within a specified period of time. For more info, see Configure temporary access.
This approach provides the least user friction. The content is accessible to anyone with the link and the temporary access token. Users only have access for the duration of time specified in the token, which is generated once the initiator starts the activity.
You can share a token using the activity starting state. The token can be redeemed for temporary content access. The temporary access token is independent of the time the content is created. This approach works for new and existing content.
The following table shows the advantages and disadvantages of using this approach:
| Advantages | Disadvantages |
|---|---|
| Least amount of friction for users | Risk of oversharing content |
| Allows people to join after activity started | |
| Doesn't require knowledge of participants ahead of time |
Share before activity starts
An alternative approach is to design your Meet Add-on to prompt the user starting the activity to update permissions before beginning.
The following table shows the advantages and disadvantages of using this approach:
| Advantages | Disadvantages |
|---|---|
| Explicit sharing minimizes risks | Determining participants can be challenging |
| Medium amount of friction or interruptions approving access as people join |
Share on-demand
This is a reactive approach where the activity initiator approves requests in real-time as users request access to the content. This method might cause high user friction if participants aren't correctly determined. Therefore, it's the least recommended.
The following table shows the advantages and disadvantages of using this approach:
| Advantages | Disadvantages |
|---|---|
| Doesn't require knowledge of participants ahead of time | Triggers high friction and interrupts the flow of the meeting |
| Explicit sharing minimizes risks | Requires a path to update the content permissions after activity has started |