Hi REST experts,
I’m doing some integration developments on E10.2.600 with Jitterbit and need to switch over to token authentication for security reasons. I’m using Jitterbit Studio, not the Cloud version.
3 questions around this:
Anyone done anything similar with Jitterbit yet and would share the apporach? Wondering if I have to do a catch on every operation sending a request to Epicor within the wortkflow as the token could drop out at any time…
Anyone knows where to control the token lifecycle in Epicor?
I saw a thread here but can’t find it for my life, where someone mentioned there are plans to join user (authentication) and access scope which would simplify the call particularly for Integration accounts. That’s exactly what a supplier of us just did in a freight integration piece I did.
Thanks all
Cheers
Time of the token life is in the admin console and defaults to 1 hr Bearer Token Expiration
3.I was under the impression that you could apply an access scope to a user account already. I think it is the API key that you really want and have the scope tied to that. If the token expires during the jitterbit processing, then perhaps you need to check for that. Although I would have though that while the task was processing there would be some sort of keep-alive happening with the token on the server side. Not 100% sure there.
With regards to the post about joining of user auth with access sope perhaps it was this post .
Thank you Simon, great help, appreciated.
Yes you link the Scope to the user, so that when you authenticate it is clear which scope you have, and this is working perfectly.
The challenge I’m seeing with token or base auth is you’re still providing uer name/pw across the web all the time.
When for example I publish my API in Jitterbit, I set am API Key which allows the user to connect directly, same does my freight supplier.
What is the benefit of separate Authentication an Access Scope?
That’s the bit I just don’t understand yet. Particularly for integration accounts, where you make sure they only have a very restricted access, it would simplify connection and you’re less at a risk exposing an epicor user/pw.
Am I thinking the wrong way?
Cheers
Andreas
Hello @Wunschi ,
Separating the Authentication and Access Scope does two things.
It allows you apply access scopes to users if you are not using token authentication
It also allows a layer of security for v1 Rest APIs.
In order to use token authentication you generate a bearer token in the first interaction with the API which is passed back to the client. For subsequent interactions the token is used as the authentication method instead of username and password.
Using token auth is mentioned on the REST API help page in the Security and Custom headers section.
So in Jitterbit, the first thing you would need to do is run the TokenResource.svc POST method to get the bearer token, store that as a variable so it can be used in subsequent steps. I’m making the assumption her that Jitterbit works a bit like Service Connect or other tools (Dell Boomi, Azure Functions etc).
Not sure if you have seen this video or not. Token Authentication for REST - YouTube. It gives a good overview and shows the process working using Postman. I’m assuming you’ve been using Postman for initial testing?
Hi @Hally ,
Thanks for the quick response.
It seems like we have to live with this process for the time being.
IMO there is work to be done, particularly being able to “switch off” v1 and provide a more streamlined option for integration accounts. It just creates an unncessary burden on the integration development.
I understand the process involved, but it means not only do I need to get the token, I also have monitor each subsequent epicor call for a 401 Forbidden to refresh the token, correct?
Anyway, at least I know there’s no other way and will proceed.
Appreciate your help.
Cheers
I think it depends on the jitterbit process. My understanding is that a new bearer token is created when the workflow starts, so if it doesn’t run longer than an hour it should not matter.
My other understanding of the token expiry is that it can be adjusted in the app server settings, by default it is 1hour.
You may also be able to limit the access use of the v1 apis at the IIS level, untested of course and you would want to find out more via tech support how to disable, but keep v2 going.
On one side thats correct, but that means I would request a new token on every call, thus submitting user/pw with every call, which defeates the purpose of getting a token from a security perspective in the first place. If someone traces the communication they get the gist.
In our case the default expiration was acutally set to 100hrs But I know now where to adjust it.
My thought is like this, if I conly get the token every hour, I reduce the amount of calls providing user/pw
and through the scope the potential damage done is very limited. Acutally would rather increase the expiration time.
If someone knows user/pw and about v1 they can cause more damage. So yes defenitely need to find out how to prevent v1 from being called. Guess we can filter our ports on that, quite restricted already.
I understand. I did a quick google with regards to jitterbit and bearer token and came up with these two links. My knowledge of Jitterbit is pretty limited, but it makes sense where you would do the call to the token.svc and then store the result. I’m not sure if jitterbit has the ability to retain the data over instances of the same workflow. I’m not a real fan of storing the token somewhere as it really defeats the purpose.
Perhaps other people who use REST v2 here might have suggestions. Jitterbit is an Epicor Partner, or I thought they were, so they might also have the answer.
Hi Hally,
Thanks for all the info, yeah I used to work with Craig for many years, great guy.
I don’t have a problem getting the token in Jitterbit, I just believe there is currently an overlap in Epicor and with v2 it’s been superseded.
I bet in a future release v1 will be retired and the user will be combined with the access scope in one api-key. Any reason to submit user/pw should be minimized.
Mark my words
Cheers
But I know now where to adjust it.