Direct login migration

This guide is to help developers to migrate their application off of the password grant (direct login) flow, which created OAuth tokens by providing their username and password.

IMPORTANT: New OAuth clients created on this site will not work with a password grant flow. Any client with the password grant enabled will continue to work for the known future.

Obtaining a token in this method looked like the following.

curl -X 'POST' 'https://api.getgo.com/oauth/v2/token'\
  -H 'Authorization: Basic base64(my_client:client_secret)' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'grant_type=password&username=my_user@example.com&password=my_password'

This flow is deprecated in favor of using the authorization_code grant type; documented in the How to obtain an access token guide. Paired with refresh tokens; documented in the How to obtain and use refresh tokens guide.

Why is the password grant flow being deprecated?

The password grant type is a way to exchange a user's credentials for an access token. Because the client application has to collect the user's password and send it to the authorization server, it is not recommended that this grant be used at all anymore. This flow provides no mechanism for things like multifactor authentication or delegated accounts, so is quite limiting in practice. Also your end users will not be able to accept or deny the authorization scopes which means that they can't control the scope of data that your integration will access on their behalf.

The latest OAuth 2.0 Security Best Current Practice disallows the password grant entirely.

Common Use Cases

Integrations with Browser Access for GoTo End Users

If your integration offers a browser access and your end users all have GoTo credentials, which means for instance that they can access a GoTo app with these credentials, then you can use the authorization code grant flow for your integration. Your end users will have to enter the credentials that you use for the password grant flow.

Just follow How to obtain an access token guide to get an access token for your users. If you were refreshing the access token of your users in the background for your integration, you can still do it via refresh tokens, see the guide How to obtain and use refresh tokens for it.

Integrations with System Users

If the username and password that you use in the password grant flow doesn’t represent real end users, the authorization code flow might not be a good fit for your integration. The process for migrating clients like yours will be defined later and you can continue to use the password grant flow until then.

Caveats to the Authorization Code grant and Refresh Tokens.

Distributing Refresh Tokens

When a refresh token exchange returns a new refresh token / access token pair; the old refresh token is invalidated. This means if the refresh token was distributed, the new refresh token must also be re-distributed.

Human Interaction

A human must authenticate at least once in the authorization_code grant flow. After which the code will be exchanged by your service for a refresh token which it can then use continuously to obtain access tokens.

Refresh Tokens Expire

When refresh tokens are close to expiration, the endpoint used to exchange the refresh token for an access token will also return a new refresh token. However if the refresh token expires before this exchange takes place, your token will then expire and be considered invalid. At which point the user represented by the refresh token must authenticate again to provide a new authorization code via the authorization_code grant.

GoTo Assist Corporate API

The Goto Assist Corporate API will not be accessible with the authorization_code grant flow.