Skip to main content
Support Center
Help ArticlesAcademyCommunity
HomeCommunitySDK/APIAdd-insHow to call my own API from Geotab Drive add-in?

How to call my own API from Geotab Drive add-in?

Solved
SDK/API
Add-ins
E
E
ELuht-2069
Original Poster

Edited by ELuht-2069

I am developing an add-in for Geotab Drive. I want my add-in to call my own API (hosted on prem) which uses a bearer token for authentication. As we know, the add-in is front end only so I cannot store my secrets there. Where should I store the secrets securely to be able to obtain the token to then call my API from the add-in? My other apps store them in key vault, but it's not obvious how to implement that here. Should there be some sort of back-end proxy going on here? All I have now is a React add-in running locally. Please advise.

5
Join the conversation

You need to be logged in to reply to this post and participate in the Geotab Community discussions.

Top Answers

M
M
misamc-2044

Hi, that's an excellent and crucial question for building secure integrations.

The short answer is: You are correct, you should not store secrets in the front-end Add-In. You need a backend proxy.

Storing secrets like a bearer token directly in your React Add-In is a significant security risk, as anyone could extract them from the client-side code.

The correct and industry-standard approach is to use a Backend for Frontend (BFF) or Proxy Pattern. Here is the recommended workflow:

  1. The Add-In calls your backend: When the Add-In needs data, it makes a request to your own backend service (e.g., an Azure Function, AWS Lambda, or a simple Node.js server). It does not call your final API directly.
  2. Authenticate the Add-In (Optional but Recommended): Your backend can verify that the request is legitimate by validating the JWT (JSON Web Token) claims that Geotab passes to the Add-In. This ensures your backend only serves requests from an authenticated Geotab session.
  3. The backend handles the secrets: Your backend service securely stores the API keys or other secrets needed to get the bearer token (using environment variables, a Key Vault, etc.). It then requests the token from your authentication provider.
  4. The backend calls your API: With the bearer token, your backend calls your protected API, gets the data, and then passes it back to the Add-In.

This way, your secrets are never exposed to the client.

As I'm not a full-time developer myself, I would appreciate it if some of the other developers here could corroborate my comments or add their own insights.

From my research, this approach is based on the "Backend for Frontend (BFF)" architectural pattern, which is the standard and secure way to solve this problem.

Best Answer

5 Replies

M
M
misamc-2044

Hi, that's an excellent and crucial question for building secure integrations.

The short answer is: You are correct, you should not store secrets in the front-end Add-In. You need a backend proxy.

Storing secrets like a bearer token directly in your React Add-In is a significant security risk, as anyone could extract them from the client-side code.

The correct and industry-standard approach is to use a Backend for Frontend (BFF) or Proxy Pattern. Here is the recommended workflow:

  1. The Add-In calls your backend: When the Add-In needs data, it makes a request to your own backend service (e.g., an Azure Function, AWS Lambda, or a simple Node.js server). It does not call your final API directly.
  2. Authenticate the Add-In (Optional but Recommended): Your backend can verify that the request is legitimate by validating the JWT (JSON Web Token) claims that Geotab passes to the Add-In. This ensures your backend only serves requests from an authenticated Geotab session.
  3. The backend handles the secrets: Your backend service securely stores the API keys or other secrets needed to get the bearer token (using environment variables, a Key Vault, etc.). It then requests the token from your authentication provider.
  4. The backend calls your API: With the bearer token, your backend calls your protected API, gets the data, and then passes it back to the Add-In.

This way, your secrets are never exposed to the client.

As I'm not a full-time developer myself, I would appreciate it if some of the other developers here could corroborate my comments or add their own insights.

From my research, this approach is based on the "Backend for Frontend (BFF)" architectural pattern, which is the standard and secure way to solve this problem.

Best Answer
E
E
EishiFUN
Geotabber

Thanks for providing that information @misamc-2044​ .I am wondering if this helped you get what you needed here @ELuht-2069​ 

 

Hey @TuckerBA-1087​ I was wondering if you could spot check the answer given by @misamc-2044​  or add anything else you would suggest here.

T
T
TuckerBA-1087

I would generally agree with this. I think it ultimately depends on what the Drive add-in is used for, what information will be exposed by it, etc. Depending on those answers, you could probably shortcut some of it especially if it's an add-in that is for personal use and won't be redistributed to others. There's always a risk / time trade that you have to do a value prop on to decide how much security is worth the time invested, but anything more than basic add-ins, we follow similar principles to @misamc-2044​'s answer.

E
E
EishiFUN
Geotabber

Thank you Tucker. Thank you for always being wiling to share your knowledge with our community!

E
E
ELuht-2069
Original Poster

Yes, @misamc-2044​ 's answer helped immensely. Thank you!

Still have questions?
Learn with AcademyBrowse documents