I had received an odd requirement.
Current Proxy returns:
{ “refresh_token_expires_in”: “7775999”, “refresh_token_status”: “approved”, “api_product_list”: “[nextGen-Oauth]”, “app_enduser”: “FF703B7C-004A-49A4-808E-C2698BF8C61C:62889a5a-8a41-4e47-815f-8c4cb56a166d”, “api_product_list_json”: [ “nextGen-Oauth” ], “organization_name”: “l;assesen-trial”, “developer.email”: “klassess@starbucks.com”, “token_type”: “BearerToken”, “issued_at”: “1525556675486”, “client_id”: “3r6bjRdkqnwG8v9Kb0KSOCjWS2ARnpnj”, “access_token”: “bAhzGSvXbXvV7CjVyJZtFtppMCWs”, “refresh_token”: “wGuAAhEjVHL3c17knLRsVOjSbGgplS2b”, “application_name”: “62889a5a-8a41-4e47-815f-8c4cb56a166d”, “grant_type”: “urn:ietf:params:oauth:grant-type:jwt-bearer”, “scope”: “”, “refresh_token_issued_at”: “1525556675486”, “expires_in”: “3599”, “refresh_count”: “0”, “status”: “approved” }
They want it to be reduced to a refresh token only, stripped of other information. I see two ways:
- Set generate response=false and custom build a response that looks like a refresh token.
- After getting the above, flip around and send the refresh token back immediately - THEN return the subsequent response only.
I do not like the second – slower response, more load. BUT
- I was wondering if masquerading the above response as a refresh token may have some unseen side-effect.
Personally, I prefer not to do either – but the request is from higher up the pecking order.