In this blog, I’ll walk you through setting up Token Based Authentication in NetSuite for integration via both web services options REST (Restlet) and SOAP (SuiteTalk). Token’s provide a secure authentication mechanism to connect to NetSuite without using the standard username and password and most importantly for integrations they do not expire when the credentials are changed or the password expires.
The first step in connecting to an integration is validating you are who you say you are. In NetSuite, a new authentication has come out for a more modern and security conscious way to do this. Historically NetSuite has required a user to specify their credentials in one manner or another using an ‘NLAuth’ scheme. This NLAuth is an implementation of the RFC 2617 standard and can be seen in NetSuite means of authorization for RESTlets uses.
| Header: | Value: |
| Authorization | NLAuth nlauth_account=12345, nlauth_email=NotMyEmail@techfino.com, nlauth_signature=NotMyPassword, nlauth_role=3 |
The procedure is much the same for SuiteTalk web services using a passport in the header to perform validation inside the xml payload. An application id and other detail is required with webservices as well:
NotMyEmail@techfino.com
NotMyPassword
12345
In my experience working with scripting and integrations utilizing RESTlets and webservices, I’ve always desired a more elegant way to authenticate for NetSuite. Utilizing a header with an email and password included in the scheme is a bit…old school. Most modern authentications techniques are moving away from this.
The typical best practice using the legacy method is using a generic dedicated integration user with a generic company email and a strong secure password. If necessary, the password is stored encrypted on records / custom records with role restricted access.
Even using this methodology, there now exists a password which belongs to a non-human user but still needs to be maintained and should be changed periodically. Regardless, NetSuite will enforce changing the password periodically (default is 6 months) for users. NetSuite is also a bit cryptic when a password has expired. Below is the typical error I’ll get in emails from clients of ours asking why the integration isn’t working.
{
"error":{
"code": "USER_ERROR",
"message": "Could not determine customer compid"
}
}
A little bit of digging into SuiteAnswers will yield the following explanation
The 2015.1 update brought a new authentication type, NetSuite started allowing token authorization for RESTlets and web services. In a nutshell, token authorization allows applications to interact on your behalf without using credentials. It is basically the Oauth 1.0 spec and fixes the above issues. Along with more elegance it offers numerous features/enhancements over the legacy authentication that make a great case for a switch.
The NLAuth scheme is a simple, quick authorization practice that can be setup and used easily but the advantages of token authentication greatly outweigh the additional upfront configuration. The best practices for the NLAuth scheme also require configuration and maintenance making it hard to make a case for legacy authentication moving forward. To help with the process of learning how to setup and start using TBA, we have a guide below:
We hope you find this information useful on your next Integration project! Please feel free to share your NetSuite integration tips and experiences.
