Migrating to New Token Retrieval with authentication.logmeininc.com

This guide outlines the steps to smoothly transition your authentication mechanism from api.getgo.com, which was marked as deprecated, to authentication.logmeininc.com.

Migration Timeline

The migration to the new token retrieval with authentication.logmeininc.com is very important and must be done as soon as possible. It is crucial to complete this migration as swiftly as possible to ensure uninterrupted services.

Please take note that precisely one year from the date of this document's publication, on January 15th, 2025, the old token retrieval host will be officially decommissioned. As a result, it is imperative to complete your migration before this deadline.

We urge you to prioritize this migration in order to prevent any disruptions to your services. Should you require assistance or encounter any challenges during this process, our team is here to provide guidance and support. Your timely action is greatly appreciated as we work together to ensure a seamless transition.

Acquiring an Authorization Code

To begin, you will need to get an authorization code if you are using the authorization code grant flow. If that is not your case, you can jump to the next section about how to obtain an access token.

Previously, this was achieved by sending a call, from your browser address/search field, to:

https://api.getgo.com/oauth/v2/authorize?client_id={clientID}&response_type=code

This process largely remains unchanged, with the primary modification being in the host. Replace api.getgo.com/oauth/v2 with authentication.logmeininc.com/oauth when making the request:

https://authentication.logmeininc.com/oauth/authorize?client_id={clientID}&response_type=code

For detailed steps on obtaining an authorization code, consult the official documentation.

Obtaining an Access Token

Similar to the authorization code process, the request for an access token now differs mainly in the host, shifting from api.getgo.com/oauth/v2 to authentication.logmeininc.com/oauth.

However, a significant change lies in the response payload for authorization grant flow and password grant flow. The prior implementation included supplementary details about the logged-in user, which the updated version omits.

If you are employing the implicit grant flow to authorize and secure an access token, the response payload remains unchanged, enabling you to proceed without issues. However, if you are utilizing either the authorization code grant flow or the password grant flow, the differences could have an impact on your implementation. To illustrate, the previous response payload took this form:

{
  "access_token": "eyJraWQiOiJvYXV0aHYyLmxt666...",
  "token_type": "Bearer",
  "refresh_token": "eyJraWQiOiJvYXV0aHYyLmxt999...",
  "expires_in": 3600,
  "account_key": "9999982253621659654",
  "email": "mister.jones@fakemail.com",
  "firstName": "Moon",
  "lastName": "Beam",
  "organizer_key": "8439885694023999999",
  "version": "3",
  "account_type": ""
}

While the new response payload includes only the subsequent information:

{
  "access_token": "eyJraWQiOiJvYXV0aHYyLmxt666...",
  "token_type": "Bearer",
  "refresh_token": "eyJraWQiOiJvYXV0aHYyLmxt999...",
  "expires_in": 3600,
  "scope": "users.v1.lines.read calls.v2.initiate",
  "principal": "mister.jones@fakemail.com"
}

If the user-specific details are not useful for your needs, you are all set. However, if these details are important, you can send a call to the SCIM /me API, which provides identity information of the current authenticated user and requires no token scope. Here is a quick cURL example:

curl --request GET 
  --url "https://api.getgo.com/identity/v1/Users/me" \
  --header "Authorization: Bearer eyJraWQiOiJvYXV0aHYyLmxt666..."

The table presented below outlines the required APIs to call for accessing information that was available through the now deprecated api.getgo.com/token API. It is important to understand that in this context, the term "new authentication host" pertains to authentication.logmeininc.com/oauth/token. It is also important to acknowledge that the term within parentheses means the field name within the corresponding API. For those entries lacking names enclosed in parentheses, the field name coincides precisely with what the outdated API previously provided. The exception is the account key, which has no equivalent single field either on the new authentication host or the SCIM /me API, where the account key can be found inside an array of accounts.

For more information about how to obtain an access token, consult official documentation.

Acquiring and Utilizing a Refresh Token

Similar to the process of acquiring an access token, the procedure for obtaining and utilizing a refresh token also involves making just one change to your request: changing the host from api.getgo.com/oauth/v2 to authentication.logmeininc.com/oauth.

However, the refresh token grant flow has a slight behavior difference regarding the response payload. Unlike the deprecated authentication API that always returns the refresh token, the new one only returns the refresh token when a new one is issued, meaning that the old one is expired.

So, if you are using the refresh token grant flow and the provided refresh token has not expired yet, the response payload will look like the following:

{
  "access_token": "eyJraWQiOiJvYXV0aHYyLmxt666...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "users.v1.lines.read calls.v2.initiate",
  "principal": "mister.jones@fakemail.com"
}

As you can see in the above example, there is no refresh_token field in the response body. But, if a new refresh token has been issued because the old one has expired, the response payload will look as below:

{
  "access_token": "eyJraWQiOiJvYXV0aHYyLmxt666...",
  "token_type": "Bearer",
  "refresh_token": "eyJraWQiOiJvYXV0aHYyLmxt999...",
  "expires_in": 3600,
  "scope": "users.v1.lines.read calls.v2.initiate",
  "principal": "mister.jones@fakemail.com"
}

With that in mind, make sure your application can check for this object and save/store the new refresh token when it appears. It is also important to remember that identity-related information about the authenticated user must be retrieved via the SCIM /me API, as mentioned in the previous section.

Here is a quick cURL example:

curl --request POST 
  --url "https://authentication.logmeininc.com/oauth/token" \
  --header "Content-Type: application/x-www-form-urlencoded" \
  --header "Authorization: Basic YTIwfAKeNGYtODY4YS00MzM5LTkzNGYtNGRhMmQ3ODhkMGFhOjNuYU8xMElBMmFnY3ZHKzlJOVRHRVE9PQ==" \
  --data "grant_type=refresh_token&refresh_token=eyJraWQiOiJvYXV0aHYyLmxt666..."

Refer to the official documentation for detailed guidelines about refresh token.

How to Contact Us

If you have any questions, concerns, or encounter problems during the migration process, do not hesitate to reach out to us via email at developer-support@goto.com.