This design would allow us to support other OAuth "Authorization Code Grant" providers in the future.
...
OAuthService
| Method | Description |
|---|---|
| OAuthAccessToken requestAccessToken(OAuthAuthorizationToken authToken) : OAuthAccessToken | retrieves the access token, making the necessary requests to the OAuth provider to refresh or whatever |
| ForwardCursorPagedResourceList<String> getHealthCodesGrantingAccess(StudyIdentifier studyId, String vendorIdentifier, int pageSize, String offsetKey) : ForwardCursorPagedResourceList<String> | retrieve all the health codes for accounts that have granted access to the OAuth provider at some point. They should all have refresh tokens and access tokens. |
| OAuthAccessToken getAccessToken(StudyIdentifier studyId, String vendorIdentifier, String healthCode) : OAuthAccessToken | retrieves an access token for the individual health code, making the necessary requests to the OAuth provider to refresh or whatever. |
...
| 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"
}