Dec 19, 2016 2:09 PM
Thank you for the quick response.
What we are trying to obtain is sync our database with HubSpot.
When a contact is updated in the external database we want to update the same contact inside HubSpot automatically. What is the best method of authentication in this case?
Looking at this answer your colleague David Adams gives here: OAuth via batch not interactive makes me think we have to use the API key authentication as we don’t have a human that can click and accept.
Mar 29, 2017 5:28 PM
Hi, I have the same use case as Avomot. We’re just syncing our DB with hubspot. I see that I can use an API key, but putting an API key in the query params is highly insecure, and opens up an attacker to gaining access to all of our Hubspot contacts. I suppose we could theoretically do OAuth, but we really aren’t the use case for OAuth here. This is just a user wanting to have programatic access to their own account.
There will never be any outside customers that use our “integration”. We’re just updating our own Hubspot account with our own data. We’d just like to do so securely.
What do you recommend? Thanks! - Blake
Mar 30, 2017 8:39 AM
@Blake_West OAuth is definitely a more secure way of handling the http calls. You will have to hold on to the refresh token in memory and handle refreshing your access token every 6-8 hours to prevent getting a 401 error
Mar 30, 2017 2:24 PM
@pmanca thanks for the info. I guess we’ll have to do that, though I must say this feels like overkill for our use case. Accepting API keys through custom headers (and/or Basic Auth headers) is standard API practice, and would make this use case significantly easier to implement. It seems other companies have this use case too, so I think it would be a great quick win for your API. Thanks - Blake
May 21, 2020 7:04 PM
Hi, OAuth 2 provides what you need. OAuth 2 has different authentication flows: Implicit, Authorization Code, Resource Owner Password and Client Credentials. It seems that HubSpot has only implemented the "Authorization Code". As you say, it is very insecure to send the API key in the URL. The "Client Credentials" flow allows you to send that information in the body of a POST request, and the service responds back with an Access Token that you can use in subsequent calls, without exposing the key too much. The flow "Authorization Code" is focused on web applications where a user (logged already) allow access to "his" resources through a "Consent" page. Although you could simulate that flow with a web client (not a browser), or use the flow to get an initial Access Token and a Refresh Token to renew it when it expires, it's conceptually wrong to request an Access Token on behalf of an specific user, when what we want is to authenticate the application itself, not a user. I think for integration and syncing with third party services the hubSpot team should implement the Client Credentials flow and not create a security issue with the API Key in URL.
Apr 5, 2017 5:29 PM
You can and should use OAuth2 when authenticating an application.
The thing to know/remember is that the “Refresh Token” does not expire. You need to get this once and then store it. From there you can get new “Access Tokens” as needed, because these do expire.
Use the ‘expires_in’ field from the response in the call to get the refresh token or the call to get a new access token to know how often to refresh the access token.
Apr 6, 2017 3:56 AM
I think root cause here is that the current OAuth2 implementation by HubSpot doesn’t allow for the client credentials grant type (https://tools.ietf.org/html/rfc6749#section-4.4). Anyone know if HubSpot plans to change this or move the specification of API key from query string to HTTP header?