I am trying to create a REST API (via Firebase cloud functions) and release it to my clients to allow them creating their mobile apps. The mobile apps they will be creating are used by public users. However, users are not supposed to deal with our APIs and thus authentication. So I don't need end user authentication. It's up to our clients (app makers) to use a "client id" and an "api key".
Based on what I have researched, Firebase Admin SDK might not be a good solution for this end since we're concerned about client level authentication.
I am looking for a standard solution to generate api-keys for the 3rd party clients. This key generation is not a manual process but rather a service that clients will use to obtain a key. Something like google map api for 3rd party developers. We want to keep track of whitelisted clients without needing their app users to deal with authentication.
I'd appreciate suggestions and guidelines to find the best solution for our REST APIs.
The first solution that comes to my mind is thew new Firebas App Check. It would restrict any access beside the Apps and Web pages you have whitelisted for your project. I don't know if that is possible in your usecase (how the cooperation with the other apps look like) but I would deffinitely try this first.
Related
In short: In GCP credentials can be restricted with application restriction and with API restriction, but Identity Toolkit API cannot be restricted on Expo mobile application.
-In web both restrictions work
-On android/iOS API restriction works but (as I have tested, correct me if I'm wrong) application restrictions does not
Now if using email/password authentication there is an issue.
There is a huge insecurity here as if anyone gets to know your API key (you define in initializeApp and so you connect to Firebase with and so use with Identity Toolkit API).
They can only by knowing that key call Firebase Auth REST API "Sign up with email / password" from anywhere and create users for your project!!
Am I wrong, missing something or can this be prevented somehow?
Things you can do to prevent this:
In "GCP>credentials>Identity Toolkit API" you can lower "Queries per minute" and "Queries per minute per user"
You can in "Firebase>Authentiction>Sign-in method>Manage sign-up quota" lower the quota from same IP address to minium (but does this help in case of android/iOS application?)
But there is no completely secure solution unless you can application restrict your API key as far as I know.
I got the following answer from Firebase support and since there has not been answers I will add this as correct answer for anyone looking solution for same thing or seeing this question.
First of all, I would like to thank you for choosing Firebase to
implement your application. I know that these kinds of situations
could be frustrating, let's work together to provide the best solution
for you.
I have checked your case and I would recommend that you reinforce your
Security Rules, because this is not a security risk, as long as you
secure access to the data within your project correctly for your
requirements, as it is mentioned in this external entry.
We don’t have a way to know the origin of those emails, even if they
were created by real users through your app, but if you identify fake
accounts you can use Cloud Functions to delete all emails registered
with that pattern using Auth triggers. Alternatively, you can delete
the accounts after an established time without activity using Schedule
Functions.
Additionally, if you don’t want to have users on your application, you
would probably need to use the Admin SDK and authenticate the
application by service account instead.
I have successfully deployed a Google Cloud Endpoints Developer Portal for my API running on Endpoints. I would like to provide access to testing to people outside my organisation that are not using GCP in their projects.
Login to the portal works correctly if I enable the Service Consumer role for these people (on per-email basis). However, when they open it for the first time, they are being asked to grant some extra permissions to the portal:
This form can create totally unnecessary security concerns. Does anyone know, why is it needed?
I only would like my clients to be able to test my API using a GUI, before they could start connecting their projects (not necessary on GCP) to mine. This seems to be a valid use case for me, however I might be misunderstanding some basic concepts.
Or should I submit a feature request to Google about a new role that only enables the access to the portal, and nothing else, so no such forms are shown?
Since Endpoints APIs must be explicitly shared with customers, the portal needs to verify that the logged-in user has permission to view that Endpoints API. So the short answer is that these scopes are being requested primarily so the portal can check the user's access to this API.
Longer answer is that we (the Endpoints team) are looking into if it's possible to build narrower OAuth scopes that would correspond to the access checks we perform. We agree that it's unnecessarily broad of an access request and are hoping to improve this in the future. Thanks for your comment!
Scenario: Auth0 Single Page application client. .NET Web API and Angular SPA both configured to use this client. Works great.
I'd like to add Azure API Management as a layer in front of the API. Have set up the API in the Management Portal, updated SPA to call API, tested calls from SPA, works great.
Now, I'd like to configure API Management Portal with the right security settings such that people can invoke API calls from the Developer Portal. I've used this [https://auth0.com/docs/integrations/azure-api-management/configure-azure] as a guide.
Where I'm at:
From the Developer portal, I can choose Authorization Code as an Auth type, go through a successful sign-in process with Auth0 and get back a Bearer token. However, calls made to the API always return 401. I think this is because I'm confused about how to set it up right. As I understand it:
either I follow the instructions and setup a new API client in Auth0, but if that's the case then surely it's not going to work, because tokens generated from one client aren't going to work against my SPA client? (or is there something I need to change to make it work)
or, how should I configure Azure API Management to work with a SPA application. (this would be my preferred method, having two clients in Auth0 seems 'messy'). But, don't I need an 'audience' value in my authorization endpoint URL? How do I get that?
If anyone has done this, would very much appreciate some guidance here.
Well, I didn't think I'd be back to answer my own question quite so soon. The reason is mostly rooted in my general ignorance of this stuff, combined with trying to take examples and fuse them together for my needs. Posting this to help out anyone else who finds themselves here.
Rather than take the Single Application Client in Auth0 and make it work with Azure API Management, I decided to go the other way, and make the non-interactive Client work with my SPA. This eventually 'felt' more right: the API is what I'm securing, and I should get the API Management portal working, then change my SPA to work with it.
Once I remembered/realised that I needed to update my audience in the API to match the audience set in the Client in Auth0, then the Management Portal started working. Getting the SPA to work with the API then became a challenge: I was trying to find out how to change the auth0 angular code to pass an audience to match the one the API was sending, but it kept sending the ClientID instead. (by the way, finding all that out was made easier by using https://jwt.io/ to decrypt the Bearer tokens and work out what was happening - look at the 'aud' value for the audience.
In the end, I changed my API, in the new JwtBearerAuthenticationOptions object, the TokenValidationParameters object (of type TokenValidationParameters) has a property ValidAudiences (yes, there is also a ValidAudience property, confusing) which can take multiple audiences. So, I added my ClientID to that.
The only other thing I then changed (which might be specific to me, not sure) is that I had to change the JsonWebToken Signature Algorithm value in Auth0 for my non-interactive client (advanced settings, oAuth tab) from HS256 to RS256.
With all that done, now requests from both the API Management Portal, and my SPA work.
Curious to know if this is the "right" way of doing it, or if I've done anything considered dangerous here.
Since you're able to make the validation of the jwts with the .Net API work, Only few changes are actually necessary to get this working with Azure API Management.
In API management,
Create a validate-jwt inbound policy on an Operation (or all operations)
set the audiences and issuers the same as what you've used with your .NET web api. (you can check the values in Auth0 portal if you don't know this yet)
The important field that is missing at this point is the Open ID URLs since auth0 uses RS256 by default. The url can be found in you Auth0 portal at: Applications -> your single page application -> settings -> Scroll down, Show Advanced Settings -> End points. Then copy the OpenID Configuration
Here's the reference for API management's requirement for JWT tokens
optional reading
I created a Actions on Google app with the Actions SDK. For this i used as said before the Actions SDK, firebase function for the fulfillment and firestore for storing data. All works fine.
Now i want to implement account linking to provide user specific information. I start to read the full documentation for account linking with the refers to integrate a Oauth 2.0 Server and soon. That is my first time i working with account linking and Oauth servers and now i'm totally confused. I don't understand where my auth server have to sit, how to setup it and what parameters it have to process. After reading more and searching for results i found that firebase provide Account authentication. Is it right that this firebase product is similar a Oauth server?
My next big problem is how to enabling account linking in my Actions app. In the Actions on Google documentation i found a topic how to expand the Action Package for account linking. My problem is to unterstand which information the probiertes need.
So summary, if the firebase authentication is really a Oauth server what i need to do that my app and firebase authentication works together.
Maybe everyone knows a good website for understanding the process of account linking and how it can be implemented.
UPDATE 1:
After getting the first answer for my question i started studying more about account linking and the authentication process.
After this i created following roadmap:
Create an website with a google account sing-in form and host it with firebase hosting
Set up the Oauth2 server
Interact with the linked account. Save account informations in my firestore database
So i started with step one. In the firebase authentication documentation i find a example for a google login form. After modifying and hosting the example i try it. It works fine. After sing in by using the hosted website, my google account linked with my project. I checked this in my google account settings. Also the example response with a lots of data like the profile name, email address and so on. So my question at this point is. Why do i have to set up a OAuth server now? After sign in with the example form i linked my account to my project successful. And so i can start saving the received data in my firebase database and act with them in my Actions app.
UPDATE 2:
Okay . Maybey i have a general problem of understanding the right use of account linking. I try to identify the user who use my action to offer special content when he comes back next time. Or maybe create a question with his name from his google account inside the question. So in my understanding i have to link the users google account with my action and save the account information in a database to identify the use next time. So is account linking for this task the right way?
No, Firebase Authentication is not an OAuth2 server.
Firebase Authentication provides a way for you to manage user accounts for your Firebase-based web or mobile app. With the Auth UI it gives a way for users to log into that account using a variety of means (including their Google account, Facebook account, or phone number). It does not, however, provide components that an OAuth2 server provides.
Most notably, it does not provide any way for a user to log in through another client (like the Google Assistant) to gain authorization for that client. You cannot, with Firebase Authentication, issue a token to the Assistant, nor accept a token from the Assistant and verify if this is a user inside Firebase Authentication.
You need to build these components yourself. Google describes the minimum tasks that it needs to do as part of this authentication. You can use Firebase Authentication as part of this as you build such a server (for example, it is a great way to have people log in to their account and for you to verify that account), and it is reasonable to use a Firebase Database to store user tokens if you go that route, Firebase Functions might be a useful place to implement the token exchange point, and Firebase Hosting would be good to host the login page itself - but you'd need to write code that "puts it all together".
Your auth server can sit anywhere. As I said - you can do it through Firebase Functions, but you don't have it. It just needs to be able to provide some responses through web URLs at HTTPS endpoints.
Once you have done this, you need to configure the endpoints on the actions console and implement a request for account linking in your code or in the action package.
Response to Update 1
After sing in by using the hosted website, my google account linked with my project. I checked this in my google account settings.
From an OAuth perspective - no, the Google Account is not "linked" to your project.
Google has issued a token to you (that is to say, the service that you've written) that gives your service access to certain resources. Those resources include information about a particular user.
This may sound like I'm splitting semantics, but it isn't. It is fundamental to what OAuth is offering and what it means when you get an issue a token. You currently have authorization to do certain things.
Why do i have to set up a OAuth server now? After sign in with the example form i linked my account to my project successful. And so i can start saving the received data in my firebase database and act with them in my Actions app.
You haven't linked your account. You have permission to do certain things.
Furthermore, aside from "that's how they do it", you need to setup an OAuth server because you now need to do the same thing for Google - give them permission to do specific things on your server (like use it). Normally this would be involved with "logging in".
Account Linking is really a fancy term for "logging in". You need a way for users to be able to log into your server. You have an access token, but that is roughly the equivalent of having logged into Google's server.
So why do so many websites, for example, have things like "Log In using Google" or "Log In using Facebook"? Because those sites are willing to trust that if their servers can get permitted to certain information at Google or Facebook, then they can trust you. And you might be willing to accept that when they login to your site (either through the web or through Actions), but the Assistant can't assume that. They need to make sure users actually log into your site - that user's deliberately want to do so and that you deliberately want to let them in.
I'm developing an API for a project I'm involved in. The API will be consumed by an Android app, an iOS app, and a desktop website. Almost all of the API is accessible only to registered users. The API allows authentication via WSSE which is great for the mobile apps, but not so great for the website. However, I'm using Symfony2 to develop the API, and I have configured it to allow access to the API by both WSSE and/or session/cookie authentication (multiple firewalls with common security context, if you're interested).
With an API-first approach like this, I'm concerned about things being abused. Take my signup method for example. I only want it to be used by the apps or the website. However, there's nothing to stop someone writing a simple script to hammer the API with bogus signups. Then there's the concern about CSRF. Because the API is can be accessed by a logged in user, then there's a risk that this can be exploited.
I don't want the API to be public, but I don't know if this is possible given that it will be used by the website. Is there anything I can do remove (or reduce) the risks and the vulnerability exposure?
Kind regards.
For the signup brut force problem you could enable a "rate limit" for your API calls.
This blog post introduces this concept and how to use it in a Symfony2 application thanks to the RateLimitBundle.