I am developing a webapp to access data in Bigtable in Vue and hosting it on Firebase Hosting and I am using Firebase Authentication to control user access for the app. I am curious as to best practices for authentication and security when it comes to such a use case.
I've read this:
https://cloud.google.com/docs/authentication/end-user
https://cloud.google.com/bigtable/docs/authentication
Here is my question:
I was taught once that the reason we build APIs in front of SQL servers for example was because we didn't want to expose the SQL server directly to the end user and risk bad things happening. So the API sits in between to act as a layer of protection.
In the Bigtable world, Google has provided their client SDKs for Bigtable that interacts with Google APIs but it has also suggested to use service account json files in most use cases. Wouldn't this be dangerous since the service account credentials then allows anybody who somehow finds it in the app files to do read or write to Bigtable and potentially mess up the database?
Should I build an API in front of Bigtable and use Firebase Auth to check if the client is authenticated using JWT before allowing operations? Or is there some other best practice?
Also,
https://cloud.google.com/docs/authentication/end-user
This article suggests that I use OAuth, so can it be linked to Firebase Authentication somehow?
Thank you!
Related
I’d like to use the Google Cloud App Engine to serve a SPA and a REST API, both secured behind an authentication wall.
Is there any recommended way of doing this?
So far, I’ve found tutorials on how to secure an API, but not an SPA. Both ends are served from different projects, but I’d like to have a unique authentication step.
Typical flow would be:
Before serving the SPA source code, ask for authentication
Once authenticated, serve the SPA and allow the SPA to access the API resources
Thank you!
So far I’ve reviewed the documentation, it doesn't seem like there is any specific recommended way to authenticate an SPA within Google Cloud.
However, I think a pretty secure way would be to authenticate your application using the Toolkit Identity API of Google. The procedure would be to call this API from App Engine as the first necessary requirement.
This method works with Oauth2 access tokens. I think you could request for authentication credentials to your users before launching your application and granting access to the other resources/APIs.
I have been doing a lot of research into how to authenticate mobile apps with an API - I still feel a bit unsure about which flow & architecture would be better to use in my particular use case.
I think what's confusing me is some of the terminology used.
My use case:
An API & database on one server. Which holds the users & and the users resources.
A web app, which I have built and consumes the API. Hosted on the same server as the API. So it's dogfooding.
A web app, which I have built and consumes the API. Hosted on a different server to the API.
A mobile app, which I have built and consumes the API.
I'd like to be able to authenticate with the API using username & password.
The API will never be opened up for consumption by other 3rd party services except the web app and the mobile app.
Initially I felt like using the Resource Owner Password Credentials Grant flow would be sufficient. However in the docs it states that this flow should be used if "The client is absolutely trusted with the user credentials".
Since both my mobile & web apps will be built by me, I'm assuming they are seen as 1st party clients. Therefore am I right in thinking they are considered to be trusted with the user credentials? As I typically thought that when implementing oAuth, the idea would be to have the authentication server separate from the resource server. Which would allow you to have one authentication server for multiple APIs.
After reading this post: Why the Password Grant is not suitable for modern applications
It threw me off track a bit. But then, is this post talking about using this flow in my use case?
I was also looking at the Implicit Grant Tokens flow. However using this flow I couldn't really see how the user would enter their credentials first?
I also question if any of the oAuth flows is really needed for my use case and I should instead look at other ways of authenticating?
I'm really quite lost with this I would like some direction to go in with how to authenticate users in my particular case.
Thanks in advance!
I'll most likely be using Laravel to house my API and so I do have Passport available to me to implement oAuth
EDIT
From following this oauth article I've found that in all use cases of my app, I end at Password Credentials Grant flow. Would I be correct here?
Iam a student and i making my internship. Sorry for my bad englis
The situation
2 people are building an backend for an message system. There are actual and passed messages. The main backend contains all the data from all the messages. This backend pushes only actual messages to and database from an mini backend which only contains the actual alerts. These actual alerts are provided by an api to multiple front ends such as an app.
I need to do research about api gateways which can make the data in the mini backend accesable for external developers. These developers only need to register or request an account so we know which application/developer connects with our api. We don't have end users with user accounts.
The API need to be scalable because in the future (over a couple of months) this system wil replace an old system. The current system needs to be handle more then 5.000.000 requests in a couple of minutes when sending out an emergency message/alert.
My problem
I googled a lot about authentication methods and i read about OAuth2. This is only necessary for authenticate end users with an user account? I dont have that so OAuth is to complex for my situation i think. But when i look in the documentation of several API Gateways like Mulesoft, Amazon API Gateway and some more i always come back by OAuth and not by an simple authentication token system or something.
See this link and then Creating a client registration flow. This uses OAuth or do i understand this incorrectly?
So now my questions
Is there an default method such as google or facebook uses for authenticate external applications by an API key? and how is this method/framwork/idunno caled?
Is it posible that i can/need to do this with OAuth?
Some example API gateways that can fill in my wishes will be great!
Amazon Api Gateway team here.
Our service supports native API keys which satisfy simple use cases. Are you interested in a simple mechanism to authenticate clients when they access your API? Some limitations would be that it's harder to manage a large number of keys, and there wouldn't really be any authorization to specific backend resources, only authentication to access the API in general.
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-api-keys.html
OAuth is better for dynamic user bases where new users register and you want to be able to control access for existing users over time. It is also useful when users have personal data that only they should be able to access.
Jack
I'm developing a RESTful API for my app on GAE python and right now I'm trying to figure out the best way to secure this API.
I have my own member/authentication mechanism on this app.
what is the best way to do this?
having public/private key pairs
becoming an OAuth provider
HTTP authentication (seems very weak to me)
other??
First, discard HTTP Auth. It is not recommended in a true REST API since it resides on cookies.
I would go with OAuth. There's a library called appengine_oauth_provider, which could helps you to start implementing your own provider.
You can use Google Service Account for User Authentication. However, people still can register an account and use your API and surely your app engine bill will go up. They've just introduce Google Cloud Endpoints at Google I/O 2012. You will have a Client ID which will only use on your client application(Android,iOS).
Google I/O 2012 - Building Android Applications that Use Web APIs with Yaniv Inbar and Sriram Saroop
Google I/O 2012 - Building Mobile App Engine Backends for Android, iOS and the Web
If you are interested in, you should try to sign up for trusted tester at
http://endpoints-trusted-tester.appspot.com/
We are using Google Apps services in our startup for email and docs. However for some other purposes such as svn and bug tracker we have our local machines on which we have installed the required apps. All of them have their own separate credential sets.
Ideally I'd like to have one authentication (i.e. that of Google Apps) and authenticate on svn & trac etc. using them. Considering Google Apps does not support OpenID, what should be a good solution? Can I setup a server which uses a particular protocol and still nicely wraps around Google Apps authentication?
There is a Google Federated Login API now, it provides OpenID services. Also, as this guy has shown, it's easy to use Google App Engine to create an OpenID provider of your own using Google IDs as the underlying credentials. HTH.
OAuth may help, up to a point -- Google Apps' gdata APIs do support it decently, see here. Of course all this requires and concerns programming, not just system administration: but then I know for sure your question IS about programming, since it's on Stack Overflow -- if you meant to ask strictly about sysadm issues, you would of course be using serverfault.com, right?-)