Token-Based Authentication -Will this work? User A creates a Token User B with Role for integration
If my (A) user creates a token that is used by an integration and the integration is accessed by a user (B) with the role will that work, and if my user is deactivated does it deactivate the token?
Context:
I want to follow best practices. We are considering having a user separate from my own admin user to be the credentials to login and have the roles to manage our integrations. The previous “admin/accountant lead/wore too many hats” has a user that is still active in the system since I haven’t cracked into it and figured out what and where this particular user manages. I’m considering of making it an overall integration user. Is this a bad practice?
Me:
Hi everyone new user here. I have 5 years admin experience with Salesforce and about 3 months with NetSuite, and find the documentation not as informative and a bit frustrating to parse. I am fairly active at the Salesforce Exchange Discord (SFXD), an unofficial community of Admins, Developers, Architects, Vendors, and a handful of Salesforce Employees, it’s a great space and if you also Admin Salesforce check us out. I spoke on their behalf a couple of years ago for a short presentation at Dreamforce in 2018: Using Lightning Flows to Automate User Onboarding.
No. You can take a look at Error Messages for RESTlets, SOAP Web Services, and REST Web Services for a list of common errors. Although you havent really explained your scneraio very well, the token used for your integration must be an active token for an active user using an active role.
Your scenario may fall under the permission_denied section, though your actual error message may vary depending on what type of integration you have
Thanks, battk.
I’ve been reading a lot over the couple hours since I posted this question. Looks like I’ll need to assign SuiteCloud plus via the Concurrent Web Services User checkbox to a user that is already managing other integrations. The one I mentioned who is no longer with the company but the user is required or OpenAir hierarchy import breaks.
So I’m probably going to convert that user to one that manages multiple integrations and has the Concurrent Web Services User checked. Create tokens via that user for the integration i’m looking at implementing which requires it’s own custom roles to be installed.
Sorry I’m being vague, the software as a service is StitchData if that helps. Thanks again.
You should be worried if Concurrent Web Services User is relevant. Its used for older integrations that rely on username/password for session managment instead of tokens. NetSuite is currently deprecating those features, they dont like other services having username/passwords and those services don’t like expiring passwords.
Huh good to know.
That being said it sounds like a user with that enabled does get more API calls the way I read it. The help articles haven’t’ been that clear. Regardless the integration I’m working on is using token based authentication, and I don’t want to create a user for each and every integration since we are smaller NetSuite org with less than 50 seats. Unless that is considered best practice, which I will do if that is the case. Like if Celigo needs it’s own user (which is another long term project) that’s reasonable but I just don’t like the idea of having 5 users which is close to 10% of all seats each running a single integration. Seems an expensive way to integrate systems for our user commitment.
You can use the same user and just create multiple tokens from that user. Im not sure why an integration would need its own user. It makes it nice for reporting purposes, but I don’t see why it would be required.
Turnover and poor initial design with multiple admins is the need for an integration user.
Maybe I misread the documentation from how I interpreted API calls weren’t global but per user. Even this integrations own documentation recommended it to be run on its own individual user:
To connect NetSuite to Stitch, we recommend that you create a Stitch-specific role and user for us. We suggest this to ensure that Stitch doesn’t encounter issues with replication due to NetSuite’s API limitations.
Again, I have no idea how an integration specific user or role prevents anything. Ill emphasize that it may be relevant for older integrations that rely on username/password or uses the login and logout operations for sessions instead of TBA request level credentials, but those things are being deprecated and you have other problems if its relevant
How is it relevant? Well to quote you: “No.”
So a Token is not related to a user? When that user is deactivated, turned off from access, etc. The token will be inactive? That’s how I interpreted that “No.”
The token used for your integration must be an active token for an active user using an active role. If you want to start hitting edge cases, the token’s user must also be granted access to NetSuite, your token must not be revoked, the integration must not be blocked. Those are all different things, though I don’t think it was relevant to your question, which was based around inactivating an old employee.
Tokens are issused for a specific user, using a specific role, for a specific integration. Each one of those 4 things can be setup to independently make your token unusuable. All 4 need to be active for your token to work. Some of them have multiple ways of making your token unusuable, for example the token itself can both be inactivated or revoked.
