We plan to build a web client (Angular) for our project. Our Backend will be a lot of google cloud run services. How can we make sure that these services can only be called by this web application?
I understand that there are Service Account, which I can use to limit access to Cloud Run services, but how do I do that in a purely JavaScript application and without a logged in user. I just want to authenticate the application not the user.
Any advise or samples?
TL;DR: The application authentication and authorization level is managed by service account. But putting a service account key file in your Javascript app (and thus viewable by any user in their browser) is useless because your secret becomes public!
With Cloud Run, you have 2 mode: private and public
If public, no security, all the requests go to your Cloud Run service
If private, Google Front End check the identity of the requester and if they have the run.invoker permission. If so, the request pass through, else it's blocked.
For being authenticated, today, you need a service account. If you aren't on Google Cloud Platform (here in the browser of the users for example), you need a service account key file. But, if you put it in your website, it's not secure because anyone can take it and use it outside your website.
So, today, you can't do this: Either your Cloud Run is public, without any check, or private with authentication (and IAM authorization)
But, soon, at least in 2020 I hope, you should be able to put a load balancer in front of Cloud Run and to activate IAP on it. Thus, the users will be authenticated thanks to their Google account authentication cookie (SSO). However, in private mode in your browser, the user will be asked for being authenticated before going to the website. It's not authentication free, it's just authentication not manage by your own.
Related
There is plenty of tutorials and articles on this precise question but each one contradict the previous one,
I'm trying to make a signup and login reactJs pages with Firebase js sdk on the frontend, that's what I found most of youtubers devs do,
And then I found that is not secure (doing the authentication on client side).
You should use the Firebase Admin SDK (firebase.google.com/docs/admin/setup) on Firebase Cloud Functions or a self-hosted server in that case. Everything else would just be a dirty hack – PRSHL source
It's not recommended to create admin accounts on the front end as anyone could look into the code and action it themselves. source
I really want to understand if it is not secure to use it on the client side, Why does firebase provided it in the first place ?? or is there another way to properly write the auth using firebase js sdk on the frontend ? of course without using admin sdk
Or should I use firebase js sdk on the backend with express ?
I only want clear and detailed answers please !!
My best guess is that you're confused between authenticating a user client-side and the fact that Firebase provides a client-side SDK for authenticating users.
Though all you have to do to use Firebase Authentication in your app is implement its client-side SDK, there are many more parts involved in the process - and quite a few of them run on secured servers.
It's just that Firebase (and the authentication providers it supports) have implemented the server-side of the authentication process for you already and made the variables parts of the process part of the configuration that you provide either in the Firebase console, the provider's web interface, and/or in the configuration that you specify when you initialize the Firebase SDK in your client-side application code.
From the comments you now added, the second is correct and explains exactly what the risk is:
It's not recommended to create admin accounts on the front end as anyone could look into the code and action it themselves.
So while you can safely create a user account on the client (a process known as authentication), marking them as an admin (a process known as authorization) has to happen in a trusted environment as otherwise any user could make themselves an admin.
I'm hosting a static page/site on GCP App Engine (written in standard js/html/css), on a company domain ;
I know in localhost testing I can't get the user info in any way (which is fine, I'll hardcode dummy data).
But after using gcloud app deploy and running it on the engine, is there a way to obtain user info somehow? Name, email etc. Ideally just through the app somehow - or even by calling a google cloud function or something.
Nb. I have activated IAP so when hosted, the user does go through google auth on this site (all domain users are allowed in).
If you have turned on IAP, then to get the information you want, you have to look at the headers
From Google Documentation
....IAP also passes the user's identity to your backend service in the following HTTP headers.
X-Goog-Authenticated-User-Email : The user's email address
X-Goog-Authenticated-User-Id : A persistent, unique identifier for the user
Tip: Do a dump of the headers in your code to see what else you might find useful.
This is what I am trying to accomplish: I have a static website hosted with Firebase Hosting and it has a Google Forms Form. Upon clicking the submit button, I want to also send the user an email confirming that we received the form. I have written a Firebase function using an HTTP endpoint. However, that endpoint is exposed to the public. Is there any way I can protect this function? I know that we can do an auth verification with a logged-in user but I don't need the visitor to create an account to submit the form.
Thank you!
HTTP triggers deployed by the Firebase CLI are always accessible to anyone with an internet connection. The only access control is provided by Google Cloud to restrict access by IAM, which is not going to be helpful to you here.
What you should do instead is protect the endpoint to be accessible only by users signed in with Firebase Authentication. There are plenty of examples of this.
How to protect firebase Cloud Function HTTP endpoint to allow only Firebase authenticated users?
Callable functions also make it easy to check if the end user is authenticated at the time of the call.
Another possibility might be, to use req.headers["x-forwarded-for"] in order to compare the request's source IP address. It's not exactly a domain-check, because TCP/IP does not know about the DNS, but it still could be combined with a reverse lookup (or simply a list of IP address/es). It depends on the scenario (what the function actually does), because this would also work while not being authenticated. It is from where vs. who ...be aware the another Firebase hosting on the same IP address could not be told apart, but it would rule out direct access from the client-side .
Apps Script keeps asking for offline permission with Youtube's API
In Google Apps Script, access to YouTube Reporting API is Forbidden
These are very similar questions however, I am logged in as the owner. The script is in the owner's drive.
My problem
I have been trying to access YouTube Analytics Reports from the Content Owner using GAS(Google Apps Script). There are two accounts a Brand account (holds the data i.e. the video content) and a User account. They both use the same credentials(email & pwd). When authorizing as the user, I get a 403(forbidden). When authorizing as the brand, I am asked to authorize offline access again and again, stopping me from ever being able to make a request.
What I've tried...
Running from Node, using OAUTH Playground tokens, and it works. But I need to stick with GAS.
Using google-script-oauth2: to hard code credentials (similarly to the Node solution) but I couldn't set the refresh token. I got a 401(invalid credentials) - I believe the bearer token was expired
Setting up credentials for and enabling both youtube and youtube analytics APIs
scrapping old credentials and attaching a new project to GAS
removing auth in privacy settings and re-authenticating
toggling a use unsafe scripts option and repeating step 3
switching between contentOwner and channel parameters for the ids param
NOTE: I have two OAUTH2 credentials app script and the web client both are set as Web Applications.
GAS Code
function test(){
YouTubeAnalytics.Reports.query("contentOwner==id", "2017-03-01", "2017-03-31", "likes");
}
Final Thoughts
I believe there is a disconnect between the Brand and the user such that the brand is not given the same access to the OAUTH 2 token. Therefore, it never generates a refresh token. So, the request sees that I am the authorized channel owner but it can't finish the OAUTH flow.
If this is true, why, and how do I fix it? If not, what do you think could be the error?
I just realized the script is in the user account and not the brand account. Would that affect the validation?
Also on the actual channel, the user is listed as the Primary Owner.
I think the problem has to do with Apps Script's limited OAuth scopes. Open the Script Editor and navigate to Resources->Advanced Google Services and you'll see that YouTube's Reporting API is not supported. However, you can get around this by using Service Accounts. They are a pain to set up but once you get them up and running you can explicitly request the scopes required to make authorized calls on the API from GAS.
Here are a few links to get you started:
Using OAuth 2.0 for Server to Server Applications
OAuth 2.0 Scopes for Google APIs
For Using OAuth 2.0 for Server to Server Applications you'll want to scroll down to the section titled Preparing to make an authorized API call. Select the HTTP/REST tab and it should walk you thru the steps you'll need to setup a service account (you'll need to create a JWT - JSON Web Token from your Google console for use in your API calls). You'll also need to retrieve the needed OAuth scope urls for YouTube's Reporting API from the second link provided. Once you're all set up you'll be able to make requests to the API directly from Apps Script using URLFetchApp. Best of luck with your project.
One more thing. Check out Google's API Explorer listing for the YouTube Reporting API. You can get the URL endpoints (and request methods) you'll need to use in your UrlFetchApp calls by playing with the Explorer.
UPDATE 4/28/2017
Also be sure to enable the YouTube Reporting API from your Google API Console.
I'm running a webview from a cordova app and want to authenticate a user, I know they have the OAuth strategies but I need to use the email/password combination.
I'd like to keep things simple but may end up having to generate a token.
Open an InAppBrowser that loads an auth flow for firebase
Listen for that auth flow to be completed using this method: http://blogs.telerik.com/appbuilder/posts/13-12-23/cross-window-communication-with-cordova%27s-inappbrowser
Grab the result from the webview again and insert it into the webview firebase instance
I'm guessing that's not possible due to security.
My app is using Amazon login (required) so my alternative would be:
webview loads InAppBrowser with our external url
that loads Amazon auth, then generates a token for Firebase
webview listens for token and grabs it, stores it in localstorage
Edit:
In the firebase docs on logging in with a username/password, I see it returns a token for the session and more information in the authData object:
https://www.firebase.com/docs/web/guide/user-auth.html
Could I then take all the information from that object and send it back over to the cordova webview and then populate that Firebase ref with the information?
Some answers from the wonderfully helpful support at Firebase:
First:
You’re correct – anyone can make a request to sign up, and we don’t expose any capability to secure the url which people can sign up from for email / password authentication.
The main reason that we require / enable origin whitelisting for OAuth authentication, but not for email / password authentication, tends to revolve around sessioning.
The Firebase login server does not maintain sessions (via cookies or any other method), and so requests to the login server for password auth. requires a user credential (the password) for every request. CSRF is typically a risk when a malicious party can take advantage of a user’s session browser, i.e. make requests on behalf of the user to some page where cookies are automatically sent by the browser.
Furthermore, we don’t have a great way to actually do ideal origin-based whitelisting for these pure HTTP requests. We could use CORS, but would have to fall back to JSONP for older browser environments that don’t support it. To complicate matters further, PhoneGap / Cordova apps don’t have the same notion of an “origin” at all, and from the perspective of a server – the calls are indistinguishable from any malicious party making an HTTP request with the same headers.
The OAuth providers, however, use cookies for sessioning and do not require user invention for each auth. request. If you’ve approved a particular Facebook app, you won’t be shown any UI/UX or be prompted the next time that app requests your data – it will be invisible. When we do OAuth, we never have to send any user credentials to Facebook / Twitter / etc., because those are stored in browser cookies for facebook.com / twitter.com / etc. What we need to protect is a malicious party pretending to be a popular, valid Facebook app. and taking advantage of that short-circuit behavior that would get access to user data without the user’s knowledge.
My response:
So, how is that secured? If anyone can make a request to sign up from a
cordova webview (which comes from no specific url, just the app iteself)
then I can't secure from which url people can sign up from? So any site
could use our url "xxx.com" in their config and start registering
users?
That doesn't seem right to me.
I think I still need to have an external url that is whitelisted by you
guys. That would have the login form and do the auth.
But then my question is, can I transfer that auth back to my cordova app?
Is it somewhere in localStorage I can check? I'll have to run some tests.
And final response:
Sure thing – we’re happy to help. I wrote much of the original client authentication code, and can speak to the design decisions and rationale that went into it. Be sure to let me know if you have further questions there.
While we don’t store user passwords in cookies, of course, we maintain a Firebase auth. token in LocalStorage. Our authentication tokens are signed by your unique Firebase secret (so they cannot be spoofed), and can contain any arbitrary user data that would be useful in your security rules.
By default, and when using the delegated login (email + password) service, these tokens will only contain a user id to uniquely identify your users for use in your security rules. For example, you could restrict all writes or reads to a given path (e.g. write to /users/$uid/name) by the user id present in the token (“.write” = “$uid = auth.uid”). Much more information on that topic available on our website.
Your plan to spin up a server to authenticate users with Amazon and generate tokens sounds correct. This is a common pattern for our users who wish to use authentication methods that we don’t support out-of-the-box (ie Amazon OAuth) or have custom auth requirements. Note: once you’ve created those tokens and sent them down to the client, they’ll be automatically persisted for you once you call ref.authWithCustomToken(…). Subsequent restarts of the app will use the same token, as long as it has not yet expired.
This is a topic of interest to me too as I have implemented something similar , twitter digits (native android) + firebase custom login in webview.
I think, as recommended by firebase, you can use other authentication providers and then the firebase custom login.
Do you use the Amazon login in android native code ? If so after login, then generate a JWT token for firebase and use it to access firebase.
If all code is in Html/js app, then maybe you can use custom login and generate a token on your server after making sure its logged in to the Amazon.
The trouble with Android hybrid apps is the following: the JWT token (for firebase) should be created on secure system (eg. server side) not with android java code, other option for hybrid app is to do a http request to generate the token, but I find that less secure, anyone would be able to get a token by finding the URL, than I resort to generate token within android app code, you can change security key/seed for token when doing new releases.
In summary, I don't think firebase studied the problem of mobile hybrid apps.