I recently received an email from Geotab saying that our database will soon be requiring session-based authentication. All of the integrations I've built so far use the .NET SDK and the connection is created by calling 'new API(userId, password, null, database, server)'. Do I need to do anything to future proof these applications to comply with the new session-based authentication?
You need to be logged in to reply to this post and participate in the Geotab Community discussions.
Edited by DarenPorter-1148
It's mostly likely referring to session-based authentication for calls other than Authenticate. If you were making an API request using a tool like Postman, then Instead of providing the username and password in the credentials object of a Get call, for example, you would need to include a valid session token.
You shouldn't need to do anything if you're using the .NET SDK. It already applies the session token that you get from calling `await api.AuthenticateAsync()` to subsequent API requests.
Hey @DarenPorter-1148,
I haven't used the .NET SDK, so I might be wrong, but I know with the others, you would still need to store and retrieve the session manually. I don't think you want to call the AuthenticateAsync() method each time your script executes, that could still flag your integration once the new policy goes into place. We typically authenticate only if our session has expired, and once we have a valid session, we store that session either in a database or secure credential store and on subsequent executions, we grab that session ID so we don't need to call authenticate again until that session expires or is invalidated. Sessions are good for 14 days so when we're evaluating our own integrations, we only want to see our service account authenticating twice a month in the Audit Log.
Thanks,
Tucker
Edited by DarenPorter-1148
With the .NET SDK, you only need to call AuthenticateAsync() once for an API object. It then stores that information internally and applies it to subsequent API calls that it makes. It would also need to re-authenticate once the internal session expires, but as you say that should happen only a few times per month (per object). You also don't need to manually refresh expired sessions - it will handle that internally too if it was constructed with a username and password.
EDIT: Technically you don't need to explicitly call AuthenticateAsync() on the API object. It validates credentials before making other calls and will make the authenticate call itself beforehand with the credentials it was given on construction. We've found that can cause race conditions when multiple threads try to make calls on startup though, so we always ensure an explicit Authenticate is performed before we allow other calls.
Also, after inspecting the API object further, it will also automatically try to refresh expired sessions if it was initially constructed with a username and password. When it makes a call that throws an InvalidUserException, it clears out the credentials then retries the entire call, which prompts it to re-authenticate. That's obviously not possible if the API object only had a session token to begin with, so for API objects constructed from sessions, those would need to be manually recreated / refreshed on expiration.
Yeah I think that works based on the post in the Integrator's hub for the session based authentication. We typically store the sessions and reuse them across executions but I don't think that is required. For our service accounts, we only authenticate once every 14 days, but I think it's OK to authenticate once per script execution, although I know we had a customer flagged for authenticating too many times in a script they wrote. It looked like it was just once per execution, the script just executed every 15 seconds so it was a ton of authenticate requests.