Securing HTTP endpoints of Cloud Functions - GCP - google-cloud-platform

I have created CF on GCP console, some are trigggered by Firestore and some are HTTP Endpoints. I have secured former one using Firebase Auth, but the later one HTTP Endpoints are not secured as i didnt find any way to authenticate them. Please help as i am new to GCP.

Here's a code sample that shows how to only allow users that use a Firebase ID token as a Bearer in the Authorization header of the HTTP request or in a __session cookie to trigger the Cloud Function.
Alternatively this StackOverflow post may be of help.

Related

AWS api gateway upstream authentications

I have a question about aws api gateway and it's possibility about upstream authentication.
We come from a monolithic approach and we try to slice into multiple services. We introduced SSO a few weeks ago.
There are some legacy services in place with basic auth credentials or api keys used for machine to machine communication.
Now we want to introduce an api gateway to have a single entrypoint for our clients.
The gateway needs to pass multipart/form-data in form of files and simple json requests as well. The plan is to validate the users in the API Gateway and passthrough the requests to the upstream services.
The services as mentioned above have unfortunately different ways of authentication.
I tried to use AWS API Gateway HTTP API to authenticate against ab backend API secured with basic auth credentials.
The HTTP Api has the advantage that you already have a jwt authroizer in place and you don't need to build your own lambda function for that. Unfortunately you can't set the Authorization header in the HTTP API but you can do in the REST API. I'm also not sure if the REST API will handle multipart/form-data passing through to the destination service.
I already know, that the file limit is 10MB for this requests.
Alternatives like kong, krakend, tyk or others are also welcome when the provide this capabilities as easy as possible.
Thanks a lot.

Using kong api gateway jwt plugin with django microservices

I am currently playing around with the Kong API Gateway and I would like to use it to validate the authentication and the authorization of users at the gateway and restrict access to services if the user is not logged in properly.
I have already an existing authentication django microservice which issues JWTs whenever a user logs in but i cant share this tokens with the other microservices because each one of them have his own database.
So i would now like to know if i can share the JWT secret produced by django and use it for jwt plugin of kong api and also do i need to create a consumer for every users and what is the right steps to achieve that ?
Any hint would be highly appreciated.

Authenticate session with AWS API Gateway

Situation: I have an app (Next.js/React on Vercel) running on example.com. I have an api (AWS API Gateway) on api.example.com. Currently the application on example.com supports login using Auth0 as authentication provider.
Problem: I would like to be able to make authenticated requests from the application (example.com) to the api (api.example.com).
Architecturally, I was hoping for a way for the API Gateway (api.example.com) to handle the authenticated session from the app/Auth0 cookie (example.com). I thought the browser could share the cookie (since api.example.com is trusted) and the API could validate it.
But I don't see a standard way to do it. I think I could try to create some custom lambda authorizer for AWS' API Gateway. But since we're dealing with authentication, I would prefer to outsource as much as humanly possible and avoid any custom code. I just can't seem to piece together the way for API Gateway to handle the sessions, which I assumed would be a pretty common problem to solve.
Sidenote: Previously, I used the pages/api that's baked into Next.js to directly call Lambdas on AWS and expose them. With this, authentication natively works. That's the experience I'm now trying to recreate, but without the user having to take a roundtrip.
When you want to protect APIs it’s better to use JWT tokens to carry over necessary claims e.g. id of authenticated user. OpenID connect and Oauth2.0 are the standards to look into.
Auth0 has documentation of recommended authentication flow: https://auth0.com/docs/flows/authorization-code-flow
as well as example with Api Gateway’s HTTP apis: https://auth0.com/blog/securing-aws-http-apis-with-jwt-authorizers/
AWS documentation has more info about Http Apis and JWT token authorizers: https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html
If your Api gateway is using Rest apis instead of more light-way Http apis then token based Lambda authorizers are the right solution: https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html

How to test calls to an Amazon API gateway using Cognito Auth

I've got some lambdas behind Amazon's API Gateway, which is configured to restrict access to Cognito authenticated users. All works fine for users coming via a UI.
I'd like to test those APIs separately to the UI, using Postman ideally or failing that perhaps curl.
How can I send a Cognito-authenticated request via Postman, curl or similar, to the API Gateway?
Try using Insomnia as a Rest client: https://insomnia.rest/
I see it has a tab for AWS auth settings.
just have a look at the following post, i think it'd be helpful for you.
How setup header in Postman for Api Gateway authenticated with Cognito?

Using AWS API Gateway for Lumen based REST API Service with Passport authentication hosted in EC2

I am entirely newbie in Amazon Web services. Currently i am developed a REST API service using Laravel's micro frameworks called Lumen. I am using passport for token based authentication and all that working fine. I need a proxy server to hide my actual endpoints and do some other functionality so i am planning to use AWS API Proxy Gateway and host the API endpoints in EC2 instance.
i went through Build an API with HTTP Proxy Integration from Aws documentation. but there is nothing about using a custom authentication using Oauth.
My Doubts are
How to use Passport authentication when using AWS API Gateway
Is there any good method to hide my REST Endpoint from customer and need a way to change the proxy end point from time to time.
I don't know Laravel ecosystem, but:
if passport expose something like an OpenId Connect you could use Cognito Federated Identities for, precisely, federate your identity, and associate the authorized identities with a given IAM role and unauthorized with another role;
you can use an Api Gateway Custom Authorizer to perform fully customizable auth;
Try expanding your question so we could add more details...
Yes, like what BAD_SEED said, you can use API Gateway Lambda authorizer (formerly known as the custom authorizer) to do any logic to verify the token, since it's just a javascript package.
So, one option is like what auth0 does in (https://auth0.com/docs/integrations/aws-api-gateway/custom-authorizers/part-3) and (https://github.com/auth0-samples/jwt-rsa-aws-custom-authorizer). Their sample authorizer does followings:
It confirms that an OAuth2 bearer token has been passed via the Authorization header.
It confirms that the token is a JWT that has been signed using the RS256 algorithm with a specific public key
It obtains the public key by inspecting the configuration returned by a configured JWKS endpoint
It also ensures that the JWT has the required Issuer (iss claim) and Audience (aud claim)
But unfortunately, Passport does not support JWKS endpoint (which exposes public key for the token signature). So you may have to expose it by yourself.
Another option is much easier, you just make a token verification endpoint in your application, something like /users/me, and protect it with auth middleware. Then in your Lambda authorizer, call it with the token in the request to your other micro service endpoints. By this way, all token verification stuff is left to Passport, and the authorizer just executes policy based on the result of the verification.
Not very sure about what you want to reach, but API Gateway is just a proxy, so you can certainly change backend side endpoints for its frontend one, which is better not changing so often.