Learn how Finch defines connections, and how to safely disconnect all access tokens associated with a connection if needed.
connection_id
.
Let’s evaluate three different scenarios…
Company | Same |
Provider | Same |
User Credentials | Different |
Company | Different |
Provider | Same |
User Credentials | Same |
connection_id
s are different. Thus, disconnecting one won’t disconnect the other.
Company | Same |
Provider | Different |
User Credentials | Same |
provider_id
s are different. Thus, disconnecting one won’t disconnect the other.
A
authenticates to the provider Gusto via Finch Connect using Credentials X
which exists in the Gusto provider for Company C
. This creates a Connection 1
in Finch and issues an access token.
A
authenticates to Gusto again using Credentials X
for Company C
(maybe with different product permissions). Another access token is created, but there is still only a single Connection 1
to Company C
.
B
authenticates to Gusto via Finch Connect as well but with Credentials Y
which also exists in the Gusto provider for Company C
. A new access token is created, and a new Connection 2
is created. To avoid a new connection being created in this scenario, make sure to use the reauthentication link containing the connection_id.
A
sets up Company C
using another provider called JustWorks. User A
then uses Finch Connect to authenticate using Credentials Z
which exists in the new JustWorks provider for Company C
. This creates a new Connection 2
in Finch and issues an access token.
C
using the provider Gusto will be revoked. These tokens still exist technically, but they can no longer be used to call the Finch API; an Unauthorized
error will be returned.
However, the token is treated as a separate connection in scenarios 3 and 4. Disconnecting tokens associated with Connection 1
will not impact tokens associated with Connection 2
.