Home > Blog: Diary of a Cloud Expert > Guide to Using Token Based Authentication in NetSuite

Guide to Using Token Based Authentication in NetSuite

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 web services as well

<passport>

<email> NotMyEmail@techfino.com <email>

<password> NotMyPassword <password>

<account> 12345 <account>

<role internalId="3" />

</passport>

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:

restlet resolve error message - could not resolve customer compid

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.

  • No need to share and expose login information
  • No password that can expire. Tokens should be updated periodically but this is no longer driven by NetSuite.
  • Token Based Authentication can be implemented utilizing any 3rd party Oauth library
  • Tokens can be managed through the NetSuite API from RESTlets to add, update and remove access as necessary
  • Tokens are also SSO and 2FA compatible

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 created a full Token Based Authentication guide for practitioners to download and refer to when setting up Token Based Authentication for web services integration with step-by-step instructions along with sample code to test REST/SOAP endpoints. In the guide we walk you thru setting up Token Based Authentication, creating your token, and creating the Integration record needed for inbound integration via web services.

Then, we show a sample python program for invoking a RESTlet using Oauth TBA. Finally, we include a handy SuiteScript example that makes a SuiteTalk web service call to NetSuite to access Budgets, which are not exposed in the SuiteScript API.

We hope you find this information useful on your next Integration project! Please feel free to share your NetSuite integration tips and experiences.

0 Comments

Leave a Reply