Finalizing the authentication flow requires implementing a single server side endpoint. Lets walk through how to do it.
As we outlined in previous steps, after a user finishes connecting their health data through the Human Connect popup, you will get a `
sessionTokenObject` with the following parameters:
You should send this token object from the client to your server as-is (for mobile SDKs, this is referred to as the `
authURL`). On the server you need to add your `
clientSecret` property to this object. This is done so that we can verify the request came from your application. You can find this value on your app settings page in the Developer Portal. A signed payload should look like this:
Now you can POST this signed object to the tokens endpoint below. Ensure that you set the `
Content-Type` header to `
Here is an example of how you could do so in Node.js:
If the object was correctly sent you will get response like this:
|`||`||A unique ID for the Human API user. Only useable by the application that registered the user.|
|`||`||Unique token for the user. Used to query the user's health data. Should not be shared.|
|`||`||Unique token for the user. Used to launch Human Connect popup in the edit mode. This token does not give access to user's health data through the API. To retrieve the `|
|`||`||Unique ID of the developer portal app you are working with.|
|`||`||Unique user ID passed into Human Connect during initial launch. Use this to associate the returned tokens with the appropriate local user.|
You need to save `
accessToken`, and `
publicToken` somewhere in your system, and associate them with that particular user record.
**User authentication via Human Connect is now complete! **Utilize the `
accessToken` to [query the user's health data](🔗) from Human API and don't forget to pass the `
publicToken` to the Human Connect popup next time the user tries to add or remove a source.
Also, see [Customizing Human Connect](🔗) page for info on customizing the language and format of the Human Connect popup.
When accessTokens and publicTokens refresh
As users connect additional data sources within Connect, the system triggers the finish callback and sends a new accessToken and publicToken for the user. These new tokens must be saved in your local user record.
As users disconnect sources within Connect, the scenario does not trigger the finish callback. The validity of the original accessToken and publicToken for the user is therefore maintained.
# Retrieve the `
publicToken` for an Existing User
In the event that you've forgotten to save a user's `
publicToken`, you can retrieve it by POSTing the appropriate `
clientId`, and `
clientSecret` to the publicTokens endpoint below. Ensure that you set the `
Content-Type` header to `
The payload will have the following properties:
The response to this query will have the `
humanId` and the new `