https://netsuiteprofessionals.com logo
Join Slack
Powered by
For extra context: Netsuite Restlet would be recei...
# suitescript
c
For extra context: Netsuite Restlet would be receiving JSON to create a vendor or customer.
e
We use OAuth1 for system integrations with NetSuite.
c
yea that's the other problem. Our system doesn't support OAuth1.0, but does support OAuth2.0. There are new people on the team trying to get this working and they are asking me questions where I thought we had been over. Is all TBA authentication Oauth1.0? OAuth2.0 has Authorization Code Grant, but as I recall had a browser pop up for a consent screen. We then waited for Oauth 2.0 machine to machine grant and found out our system doesn't support JWT. I am not a developer myself, but got it working in postman and we had a slight work around in our system, but the problem has been getting the client assertion token since it's a pre-request script in my postman.
b
oauth 1 remains the best chance for integration
the authorization code grant is mostly useless
support for the client credentials grant is rare, it uses jwt assertions, which is currently a draft
c
is Token-based Authentication based on Oauth1.0? The team came to me asking about TBA and I said that I am pretty sure that is all Oauth1.0, which our system doesn't support. When we look at what the header needs to be I see that it mentions Oauth throughout
b
tba is oauth 1 with a minor addition if you use the 3 step flow
that flow supports a non standard role parameter
c
ok so if our system doesn't support Oauth1.0, what other options would we have?
Also why do you consider authorization code grant useless? Is it because of the consent screen?
b
no options that isnt a variation of adding support for a new authorization type
the authorization grant refresh token expires in 7 days
so its useful for 7 days at a time
c
ok thats what i found out using postman
s
NetSuite's up and comer answer to this is the new Client Credentials flow - if your system doesn't support it tell them they should.
c
we waited for client credentials (machine to machine) and I got that working well on postman, but our system couldn't without extra work. I don't think our engineering has time to build out a new system so the applications team is trying to find an easier way.
The issue we had with authorization code grant is that it expired in 7 days and required clicking accept on that consent screen if i remember correctly
s
Yes, that flow isn't meant for persistent machine-machine integrations
it's meant for a system making requests on behalf of another user, and needs their authorization to do so (hence the consent screen)
c
ah ok thank you. All of this is what I thought I found out months ago, but I was having trouble remembering it all.
basically we are back to square one and I think we just need to get our team to support other authorization method
s
Yes, support one of the methods intended for machine-machine integration like that. E.g. OAuth 1.0 (TBA) or the new Client Credentials stuff in OAuth2. As far as I'm concerned, a team can't stop TBA support unless they also enable its OAuth2 spiritual successor (Client Credentials). Unless they don't mind breaking things.
c
We only have a few integrations and we were grandfathered in via user/pass 😐 I have been trying to get them to update which is why I have been testing items myself and showing it to them as a proof of concept.
s
well, sounds like you're doing what you can!
c
Thanks for all the information
e
The only way I got client credentials to work was to create a .NET console app running on an AWS server that authenticated to a NS RESTlet via OAuth 2.0 with the .NET console app generating the JWT. After it got the data it needed it had to pass it on to an external system's API that had its own authentication protocols so the .NET console app middleware approach worked well.
s
on a related note, I confirmed JWT creation (signing with a shared secret) and subsequent use works OK in SuiteScript.
c
So I am a little confused. They came back to me today and asked about setting the OAUTH 2.0 CONSENT POLICY to Never Ask and that seems like it would fix the issue we experience.
Is there a reason we shouldn't do that? Is it a security reason?
Actually I think I figured it out is that it requires the user to login still and it looked like it was working because the user was already logged in our their browser. I had them try from incognito and it broke
s
That flow is intended for a human being to consent - that's the whole idea. Anything you do to hack around that is defeating the purpose.
c
yea I explained that to them and even said I found it odd that no one here or even Netsuite themselves recommended doing it. The reason it looked like it was just working was because the user testing had logged into their chrome browser so they were never presented with a login screen. When they tried via a incognito browser it brought up the login screen. Once they logged in, they didn't have to consent again though so now they are looking into this as a possibility. I don't think it's ideal and we should just get Oauth2.0 M2M or Oauth1.0 working
s
that brings you back to the original problem I think battk mentioned - That consent will pop back up soon - and if this is a system-to-system data integration that user won't be there to haggle that screen.
b
if they think keeping a login active is feasible, its also feasible to just automate logging into netsuite and clicking yes on that consent screen
s
yucky
message has been deleted
c
@battk lol yes I mentioned that. I think they believe that since the users who would be using the integration are Finance users they would already be logged in so as long as they do the consent screen 1 time it should be good.
I said this seems very clunky and the finance users are SAML based so that's another potential issue. I think I managed to get them to forget about this method, but I shall see
Open in Slack
PreviousNext
Powered by