Skip to Main Content
  • Questions
  • Securing REST APIs in a SaaS solution

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, Rodney.

Asked: January 12, 2025 - 6:21 pm UTC

Last updated: February 17, 2025 - 7:49 am UTC

Version: Oracle 19c

Viewed 100+ times

You Asked

I am working on a Business SaaS solution and my data is siloed using a tenant_id column. I am setting up REST APIs using ORDS (v24). The application will provide the ability to POST and GET the subscribers data. Each subscriber will be provided their own set of credentials for the REST API. In calls to the API, I am requiring the tenant_id to be passed in via the headers. It occurs to me that even though I am securing the API behind a set of credentials, there is nothing to prevent the subscriber from using their credentials to access the API, but spoof their tenant_id in the headers by simply guessing a different tenant_id. Is there a way in ORDS to identify the user accessing the API so that I can map that user to the tenant_id? If not, I already activate a fake application user primarily for the purposes of logging the transactions. So, I've considered securing that user with a password and requiring the password to also be passed in the headers. I appreciate your advice on the best approach to use.

and Connor said...

Thanks for your patience.

I'll ask around internally - but is it feasible to have a simple mapping between tenant and a random value (eg GUID), so that calls pass in the GUID in the header, which you then map to the tenant_id using a simple lookup table.

No-one is going to be guessing GUID's any time soon

Rating

  (1 rating)

Comments

GUID

Rodney, February 14, 2025 - 12:50 pm UTC

Yes, basically that was the plan for "password" was to pass in something along the lines of a GUID. I would definitely be curious to know if there is a context variable available in ORDS for the CLIENT_ID when OAUTH credentials are used to access a REST service. But the GUID plan will work. Thanks!
Connor McDonald
February 17, 2025 - 7:49 am UTC

I'll report back with any findings

More to Explore

Security

All of the vital components for a secure database are covered in the Security guide.