I have an AddOn built that I am able to launch from the ServiceM8 app and Desktop, and within it is use the Auth token to perform some work.
Once that work is done, I need to send it to a front end application with job information I have gained from the auth token.
When the front end app work is complete, I then need to interact with the back end again and I need authorisation to do that. Sending the auth token to the front end and back again presents as a security issue, as it means that credentials are exposed along the way.
For the same AddOn, am I also able to set up an Access and Refresh key pair, so that it can generate an auth token when triggered, and then the Access and Refresh token pair when the front end is complete and I have to complete more server side work?
If you’re using an Add-on SDK serverless add-on, authentication in the function is handled by ServiceM8’s token service, which provides a temporary OAuth token each time your function is invoked.
That serverless access token is short-lived (900 seconds) and you receive a new one every time the function is invoked.
The access and refresh token pair you mentioned comes from the standard OAuth 2.0 flow: when you exchange the authorization code, you receive an access token plus a refresh token.
Access tokens expire (currently one hour), and you use the refresh token (refresh_token grant type) to obtain a new access token.
So, if you need your back end to keep calling the ServiceM8 API after an external front-end step completes, the documented approach is to use the full OAuth 2.0 model rather than relying on the per-invocation serverless token.
For Web Service Hosted add-ons specifically, OAuth is mandatory and you implement the OAuth2 flow between your app and ServiceM8.
Reply with whether you’re running this as a Lambda (Serverless) add-on or a Web Service Hosted add-on, and we’ll confirm which auth setup fits best.
I’m running Lambda Addons launched from within the ServiceM8 app. It contacts my Backend Process with information about the job that launched the Lambda.
Currently, the Backend Process uses the shortlived Serverless Token when they do this, but I don’t want to pass the Serverless token to the Front End for Security Reasons.
When the Front End contacts the Backend Process again, I need to Authenticate again, as the Serverless Token is not retained between these two steps (so that they cannot be intercepted). The way I can do that is with OAuth2, but I’m uncertain that if I use Serverless Tokens and OAuth2 tied to the same Addon, if that will break things.
When ServiceM8 invokes your Lambda function, the event payload can include auth.accessToken (issued by the Secure Token Service), and your add-on receives a new access token every time your Lambda function is invoked.
That Secure Token Service access token is short-lived (900 seconds) and is issued per invocation.
Serverless OAuth is designed so you don’t need to implement the OAuth access token flow or manage user accounts, and you use the temporary token “for that one specific task”.
If you need an access/refresh token pair for ongoing API access beyond a single invocation, that comes from the standard OAuth 2.0 authorization flow, where the token response contains an access token plus a refresh token, and you can obtain a new access token using the refresh_token grant type (access tokens have a 3600 second lifetime).
If this is only for one ServiceM8 account, you can also authenticate to the REST API using an API Key (sent in the X-API-Key header).
Can you confirm whether this add-on is private to a single account or intended for wider distribution via the Add-on Store?