This design would allow us to support other OAuth "Authorization Code Grant" providers in the future.
Style note: given Java naming conventions and the way they translate to JSON properties, Will consistently use Oauth and not OAuth.
API
| authenticated users | POST /v3/oauth/:vendorId |
|---|---|
| body | {"authCode":"<authCode>"} |
| if auth code provided in post | get access and refresh tokens |
| no authCode provided, accessToken exists, not expired | return access token |
| no authCode provided, accessToken exists, expired | refresh access token, return new access token |
| 401 | no authCode, no accessToken, or an error |
| 200 | {"vendorId":"vendorId","accessToken":"<accessToken>","expiresOn":"<ISO 8601 timestamp>"} |
...
| 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"
}