Extend TokenResource.svc ExpiresIn

Hello,

Anyone know if there is a way when calling the TokenResource.svc endpoint to have the ExpiresIn be more than 1hr, or is there a way to refresh an access token using the rest api?

Thank you,

Ted

Hey Ted,

The current practice is to implement a retry pattern. Here’s an example that uses a popular NuGet package called Polly. This works with tokens or when API-Keys expire.

Retry and fallback policies in C# with Polly · Jacob’s Blog (duijzer.com)

1 Like

I am not using the TokenSvc but I do utilize Sessions in my application. The pattern I use is 2 fold; upon start, a worker service grabs a session and then refreshes it on a schedule if nothing else happens. Secondly, each call to the application passes through a validation service to ensure the session is still valid and if not, grabs a new one.
I wonder if something similar can be achieved with the TokenSvc

The problem we are facing is that we only want to have the user enter their username/password once and then expire the token/session after a time we deem appropriate

There is no refresh token in the internal TokenResource.svc.

You can extend token lifetime in the Admin Console - Server Managerment - Configure Token Authentication.

3 Likes

Bearer Token vs Basic.

I understand using Bearer Tokens is the way forward and not Basic Authentication username/password. But I wonder if there is any real world benefit in Epicor? I assumed the Bearer Token approach is faster than Basic Authentication for repeated calls, but in testing this theory I didn’t see any performance improvement. Put that together with the additional workarounds in Epicor (e.g. TokenResource.svc doesn’t handle token refresh etc), Basic still seems the way go to? - don’t @ me :roll_eyes: .

Putting my case forward…

I assumed (probably incorrectly) that using Basic authentication would re-evaluate the username password then process the request on every request. The other assumption being if its using a Bearer token, the evaluation would be done on the first call, then avoid the overhead of reauthenticating the token on subsequent calls until it expires? Which is how I ended up on this thread, looking for a token refresh option.

I was thinking along the same lines as the post where @Bart_Elia mentiond BOReader is faster than BAQ due to the overhead of the BAQ security checks.

I’d be interested in your thoughts on this.

PS I’m on 10.2.700 if that makes any difference.

Cheers,
John’o

I let Olga answer for Epicor but the elimination of Basic Authentication is an industry move to get rid of passwords altogether. Microsoft was planning to deprecate Basic Auth in O365 but COVID-19 delayed that.

Modern Authentication (as it’s called) is the path forward mostly for security reasons in a web-based world. If people want to use a single sign on across applications, username/password does not work well. Epicor has multiple product lines (DocStar, K21, P21, KBMax, etc.) and they want to sell all of them to as many of their customers as possible. Maintaining a username/password database in each is not only inefficient, it’s not really safe. Also, Modern Authentication gives admins the ability to control authorization in a single place. Finally, Modern Authentication gives us the ability to do multifactor authentication and conditional access where the token is checked more often for certain privileged operations. All of this is not possible with Basic Authentication.

1 Like

You authenticate each call regardless authentication type - for basic auth you send name and password on each call, for token auth you send token on each call. So it is not a question of performance.
The token resource is very primitive and its only advantage is to allow client browser app not to store password anywhere in browser.
More modern implementation do much more than that - they allow users login with multi-factor authentication or even without password at all. This is modern approach and should be used instead of ordinary name and password login.
In Epicor this is implemented using Epicor IDP, but it is only available to cloud customers.
All others can use Azure AD login.

1 Like

Hi Olga, thanks for your reply. Busy week so apologies for the delayed response.

Given each call is reauthenticated regardless of basic auth or token, there isn’t a performance gain using one or the other - token makes sense. Thanks for your feedback.

As a cloud customer 10.2.700 SLS, we are already using Azure AD. Are there any good examples you can point me too?

Separately but related:

We have another challenge as we use DocStar (SaaS) as well. When we implemented Epicor originally 10.2 300, Epicor and DocStar authentication only supported username/password.

DocStar supported SAML2, Windows SSO (on-prem only) and username password. Epicor Supported username/password, Windows SSO (on-prem) and Azure AD. Username/password was the only common ground for cloud customers.

Example, I’m in Epicor and attach a file, Epicor pops up a username/password prompting to authenticate to DocStar before passing the attachment through.

We were told when Epicor IDP was available both Epicor and DocStar it would work seemlessly.

Do you know if this issue has been resolved now?

Thanks for your reply @Mark_Wonsil and @Olga

yes, both Epicor Kinetic and Docstar can work with IDP

1 Like