This design would allow us to support other OAuth "Authorization Code Grant" providers in the future.
...
| OAuthAccessGrant |
|---|
| String studyId:vendor (hashKey) String healthCode (rangeKey) String accessToken String refreshToken Long createdOn Long expiresOn |
| OAuthAccessToken |
|---|
| String vendorId String accessToken DateTime expiresOn |
| OAuthAuthorizationToken |
|---|
String vendorId |
| UserSessionInfo |
|---|
| Map<String,OAuthAccessToken> accessTokens |
Fitbit access token response
This is the JSON returned by Fitbit... not sure if this is defined by the OAuth specification or not, but seems like it would have to be and can be standardized in code for the Authorization Code Grant workflow.
{
"access_token": "eyJhbGciOTnSWz_qlqoEpUlpc",
"expires_in": 3600,
"refresh_token": "c643a63c072f0f05478e9d18b991db80ef6061e4f8e6c822d83fed53e5fafdd7",
"token_type": "Bearer",
"user_id": "26FWFL"
}