Authentication/Authorization options for PostgREST when used as existing API's ORM behind Apigee

[bartekus]

This is not an issue per se, but rather a general question that pertain to a specific Cloud SQL use case.

I'm working currently on a production grade platform that consists of few micro-services that are securely sitting behind enterprise Apigee that performs all the required security related authentication tasks and attaches basic authentication header which encodes client_id and client_secret as base64 encoded token in this format: Basic client_id.client_secret.

With this in place, our api acts as gateway hub that utilizes PostgREST as a db-service (to decouple the necessity of using ORM) and so far has relied on anonymous user role which has been given A LOT of access permissions to permit unauthenticated use that mimics that of your typical ORM (minus crippled access control).

We have used subzero's PostgREST template as a starting point so that we can facilitate the future needs, therefore we have proper roles and permissions accounted for/already set, altho voided in light of glorifying anonymous role and granting it all read-write access in an unauthenticated way.

That being said, this approach is not a good one in the long term, even in the context of our use (nothing outside the api that sits in front of it can access the db-service) especially given the intend to create an web based admin portal which itself will be using the token based authentication (as provided by subzero template starting point).

Given these realities, would would be some of the suggested approaches so that we could negate necessity of login/signup (and token generation at the db level) as per API requirements while also enabling the future admin portal requirements (already facilitated by db level authentication using signed tokens.

[steve-chavez]

would would be some of the suggested approaches so that we could negate necessity of login/signup (and token generation at the db level)

You'd need an additional authn service for this, there are some examples in https://postgrest.org/en/stable/ecosystem.html#extensions.

There's also supabase/gotrue(used heavily in production), which produces JWTs that can be consumed by PostgREST.

[bartekus]

Thank you, this give me some ideas.
I'll get back here once I figure something out to share the solution for reference.
Perhaps others might benefit from it as well.