I'm developing an application following quite closely Feldman Elm SPA example with the API hosted on AWS API Gateway. My problem is the following:
I need to sign my API calls with AWS API Signature v4. It is a less trivial task than I initially thought in Elm:
There is no Elm AWS signature package, so I naturally looked at JS libraries to use via Ports.
Option 1: Use AWS Amplify API that does all the job => But then how to process the result in the most Elm-esque way (ideally with RemoteData).
Option 2: Use a third-party JS library just to sign the request forged by Elm Http.request and send send/process the HTTP request via Elm => So far I found only buggy implementations of AWS Sigv4, I would prefer an official implementation anyway.
In the 2 cases, I'm stuck with the Main Parent / Page Children communication: I can send the request 1) or 2) via Port from the Child. But then, how to can the Child receive the response to his request? Indeed, all responses go into Elm via the same port subscription. Do I need to 'tag' the outgoing requests and then dispatch the response based on the tag? But it will look horrible and won't scale well.
Please note that it is a question about App pattern and architecture. It is not a basic question about Elm Ports (I already successfully call the API from Elm).
Any recommendations or pointers appreciated. Thanks!
Additional info about my setup (following the first comment)
I follow the AWS best practices (scenario #3 Access Resources with API Gateway and Lambda with a User Pool)
Front-end App users are managed by:
Cognito User Pool (signup, sign-in, etc...)
Cognito Identity Pool (map users with IAM role to access AWS resources, including the API Gateway)
Back-end is Serverless: API Gateway + Lambda functions
API Gateway: Lambda proxy integration + Authorization = IAM => this requires the AWS Signature
I don't use API keys because:
I don't want to provide any access to the back-end to unauthenticated users
I need to identify the user from the request headers
I don't want to rely on long-term secrets for authentication on client side
Related
I need to implement a scenario where, after a file is uploaded to Google Cloud Storage, a function is triggered and processes the file. In this case, processing basically means sanitizing the file, storing it into Firestore and making it accessible via another HTTP-triggered function (a REST API of sorts).
Both user-facing ends of this process (a file upload and HTTP function) need to be secured. The process will be used in server-to-server scenario: one side is going to be a backend written in either Node.js or .NET, the other will be my Firebase solution (Cloud Storage and HTTP-triggered function as per above). In Firebase, I am going to maintain a custom set of users that should have access to the system - my idea was to use a simple system where each user will have a client id and a client secret (basically an oAuth client credentials grant type).
Based on what I read online, an only option to implement this is to use [Firebase auth with custom tokens][1]. I found lots of examples online on how to do that, but it was always about client-to-server scenarios (e.g. a Javascript web app talking to REST API). Server-to-server scenarios were not mentioned anywhere and indeed, I am unsure how to go about implementing it - I can call auth.createCustomToken(uid) just fine in my HTTP Firestore function, but there seem to be no server-side libraries I could use to call auth.SignInWithCustomTokenAsync(customToken).
To sum it up:
How can I use Firebase auth with custom tokens in server-to-server
scenario, where I need to sign in using a previously generated
custom token from a server environment?
If it is not possible,
what's the other alternative to securely implement the
above-described architecture?
I've contacted Google Support and if anyone else is struggling with this, in server-side scenarios, recommended approach is to call signInWithCustomToken endpoint in Firebase Auth REST API.
after reading this answer https://stackoverflow.com/a/51614256/15486192 from #Arsam, i am successfully sending data from nodeMcu esp8266 to firebase.
but i am using Database secrets Although it is deprecated.
and while searching for an alternative i came across firebase REST
Firebase Database REST API
API Usage
You can use any Firebase Realtime Database URL as a REST
endpoint. All you need to do is append .json to the end of the URL and
send a request from your favorite HTTPS client.
HTTPS is required. Firebase only responds to encrypted traffic so that your data remains safe.
after reading that, anyone conclude that you can send data to firebase using HTTPS request.
so my questions,
is REST API just an HTTP request?
i am just confused if it is, then why just not naming it HTTP API?
can i send my data to firebase Realtime-database using only https request from my client?if yes then how
REST or RESTful API design (Representational State Transfer) is designed to take advantage of existing protocols. While REST can be used over nearly any protocol, it usually takes advantage of HTTP when used for Web APIs.
Be carefull when using the REST API on the client side!
The REST API for the Firebase RTDB is usualy ment for development of code where you don't wand or can't use the official SDKs. For example when you code in a language that doesn't have a official Firebase SDK. Or also in usecases where you because of perfromacne reasons don't want to use the SDKs. In most cases landing pages.
BUT. The REST API is very handy for public data in your database. And I would only recommend to leave public data only the read access. Othervise anyone could fill up your database with knowing your REST API.
So if you plan to use the RTDB on your client side try to use official SDK because the handle the security for you.
David East even had a talk on the last Google IO on how to improve the loading time for laning pages by removing the Firebase SDKs and using the REST API. But that was also only for public data.
If you want to use it on a server from the backend you can use also the REST API. Here is the documentation for using the REST API and here for the authentication part of it.
I have a simple web site hosted in Firebase and it is making AJAX calls to REST API endpoints in GCP Cloud Run.
I would like to limit these endpoints only to the calls coming from this site hosted in Firebase. Any call coming from any other origin should not be able to use the endpoints. What is the best way to do this?
When I was not using GCP Cloud Run, I was doing a host check on the API side to make sure that request is coming from my client but now with Cloud Run this is not possible. What else could be done?
Please note that the web-site hosted in Firebase is very simple and do not do any user authentication.
Challenge: Restrict access to a Cloud Run service to a single web application, without relying on:
Restricting access to the web application
Imposing authentication on users
This difficulty is not specific to Cloud Run. It's a general challenge for static sites backed by APIs, and a reason why many sites have authentication. As mentioned in the question comments, a server-side "host" check is not a meaningful security layer, as everything in the HTTP request can be faked. I strongly recommend you not worry about keeping your API private or add user authentication to keep the system simple and access accountable.
If that's not possible, you can still take the authentication approach by creating a single user, embedding the credentials in the site, and rotating them regularly (by redeploy to Firebase Hosting) to prevent credential theft from having indefinite access to your API. Having Firebase Auth in the middle is better than a simple API key because it prevents replay attacks from accessing your API.
I am trying to find an alternative for Firebase to create functions that will work with actions-on-google DialogFlow class. I am creating a nodeJS app which will create a web service endpoint which will be configured as the Fulfillment URL in the DialogFlow dashboard. All the business logic to handle the request from API.AI will be at the nodeJS app. This app will then send back response by calling app.ask() and other related methods of API.AI (aka DialogFlow)
Reason: Our deployment cloud is on OneOps and we have dedicated assemblies for nodeJS apps. That is, I need to deploy this node app on our OneOps cloud and not on Firebase cloud.
Is there an alternative over Firebase here?
Absolutely! With Dialogflow you can define any URL (preferable HTTPS) in Dialogflow's console and you're free to use any hosting platform that can speak HTTP:
Also, you should be able to use the Action on Google library to respond to requests on most Node.js environments
Certainly! You can use whatever you want - all that Dialogflow requires is that the webhook be on a public address with a valid HTTPS certificate.
When designing the webhook, you'll need to accept a POST request from Dialogflow that contains JSON as the body, and similarly respond with a JSON body.
Since you're using node.js, you'll likely be using Express. One thing to note if you'll be using the actions-on-google library is that it expects that Express has already populated the req.body with a JSON object - not with the string body. This is typically done with middleware such as body-parser.
We are looking into authentication/authorization for a mobile reporting app which consumes hourly/weekly/monthly commercially sensitive data over the wire using an internally provided RESTful web api service running within the MS Azure Cloud.
Stormpath's offering looks interesting in that it would appear to provide some heavy lift for the whole identity management side of things, registering users, authenticating them and producing JWT tokens etc.
Otherwise, we would have to write our own auth/user db tables and have some management overhead with that.
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Can anyone, especially those familiar with Stormath elaborate on this?
I get that all the user registration, password recovery use cases would go via Stormpath and I am guessing that JWT token creation for a user would require our existing service to talk to Stormpath. Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
I guess I am sensitive to performance issues regarding the whole token validation step within the Web API pipeline.
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet.
Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
One thing which looks attractive about something like Stormpath is the possibility of two factor authentication.
Without having gone into too much analysis yet, a typical use case scenario would be that sign up or password recovery would mandate that an SMS was sent to the user's preregistered smartphone number to provide a stronger validation that they (and their pre-registered device) are the intended user of the mobile app which uses the RESTful service to consume and visualise commercially sensitive data.
I work at Stormpath on our .NET libraries.
What I am not fully clear on is where our current unsecure, unauthenticated prototype API served up by Azure would need to intersect with Stormpath.
Stormpath acts as your API's source of access tokens. When someone using your mobile app needs to log in, your backend API uses Stormpath to generate an access token, or the mobile app talks directly to Stormpath to get an access token. Either way, the token allows the mobile app to make authenticated requests to your API.
Would the validation of tokens within the HTTP(S) headers of our RESTful calls be done by our Azure service locally (via some code plugin) and if so is that validation done locally or does each RESTful call have a side effect of proxying calls to Stormpath API to validate the goodness of a token?
The access token (JWT) integrity can be validated locally using middleware like UseJwtBearerAuthentication in ASP.NET. For more security, you can send the token up to Stormpath to be verified even further (for revocation and other cases), but the tradeoff is a network request. Local (fast) validation is the default, but we give you both options.
I've read elsewhere that Microsoft themselves have an offering, namely Azure AD B2C which it seems is not production ready for regions outside of US/North America as of yet. Is that something else we should consider as an alternative to an outsourced offering like Stormpath?
Using either Stormpath or Azure AD B2C is "outsourcing" your identity and user management. The benefit is that you don't have to write it yourself, and you can focus on writing your business and app logic instead. The features are similar, although Stormpath is a little more flexible on the mobile side of things (since you aren't forced to use a browser/page-based flow).