I am developing an native Android application using Firebase (No other custom server, only Firebase)
And it should use other services. (like Facebook API, Twitter API, etc...)
The service providers are providing the REST Api through OAuth 2.0.
I am very newbie of the OAuth 2.0, I have no knowledge, experience.
Yesterday I tried to implement "Implicit Grant", and it works fine.
I can get access_token, and I can use the REST APIs using it.
But there is a parameter "expires_in": 604800 (7 days).
This means my customer should re-authorize after 7 days. (There is no refresh_token.)
So I am considering to change the implement from "Implicit Grant" to "Authorization Code Grant".
But I already told you, I am newbie of the OAuth 2.0. (I have no experience, this is my first time.)
If I choose "Authorization Code Grant", I should store the "code" to exchange the "access_token".
Then where should I store it?
I think I can store it in local device, but it doesn't consider security.
So I want to know can I use "Firebase Realtime database/Firestore" as a storage to store "code".
I think it is reasonable.
But I am not sure...
Since you said you are a newbie , it’s worth reading more about Oauth 2.0 especially when you want to build Oauth server , a simple google search returns
https://stormpath.com/blog/what-the-heck-is-oauthhttps://stormpath.com/blog/what-the-heck-is-oauth
Fire base database alone enough to built a sever , you need endpoints to handle incoming request for you can use Cloud Functions
So if you want to implement **Authorisation Grant ** or Implicit Flow, it needs to happen in browser ,
First you can use cloud functions to handle the incoming GET request from client (in browser)
Then you return a login page where users can login,
Then handle the auth submit request from page , authenticate it , if valid generate a code or access_token (in case of implicit flow) , store that in firebase database
Return the generated code back to client using redirect uri
Finally , if Authorisation grant flow , you need another cloud functions to handle code exchange to access token
Related
I am using firebase admin sdk on the server to generate sign in links and send them out via custom SMTP api.
I just glanced at https://firebase.google.com/docs/auth/limits and I am well within these, but I believe there is nothing stopping a malicious third party from creating/requesting sign-in links via front end code. Is there a possibility to disable this functionality so it is only available to admin acc?
Additionally, I'd like some emails (i.e. multi factor enrolment) to not be possible, but again, given that someone can obtain some of my firebase front end details, they technically can send these?
You can restrict the API key from accessing an API (e.g. Identity Toolkit) but not disable a single method of the API for client.Sign up and delete user can be (that requires upgrading to Identity Platform) .
Firebase generates an API key when you add a web app. You can either update that or create a new key from API Credentials console.
You can then restrict what the API key in Firebase web config has access to:
However, Firebase Auth Client SDK will not work as Identity Toolkit is not selected. You'll have to proxy the requests through your backend and use a different key that can be used from your server's IP only.
Firebase Admin SDK will still be functional as usual so you can use that to perform other operations like updating/deleting users. You'll just have to write APIs on your backend for what could have been done using client SDK directly (or use Admin SDK when possible).
It might be a lot to update and I would not recommend unless you are facing rate limiting issues where Firebase Support should be able to help.
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.
I need to send product details to Google shopping Content API but for using that i need to generate oAuth token with refresh token throgh Azure data factory.I have generated service account and client-secret json .How i will do it through function app?
Firstly, we need to understand that functions should not be used to do UI-related actions. In any app service the pop up for the login ( which allows to provide the credentials) will not be supported.
E.g. : To avoid this scenario , in case of AD auth we may use service principle where we feed the required credential to acquire the token. So if we want to use the google auth SDK we need to connect to the concerned team ( Google team) to understand if this is feasible at all.
For this you may check the Server-To-Server Service Account Authentication, as below:
https://cloud.google.com/docs/authentication/production
In case you need any assistance in this, we would recommend you to reach out to the concerned support team.
I am building some internal API for my apps/website with Firebase Functions. Internal API as in to let my apps/website to process something on server side, its doesn't mean to open to public use.
My Apps is built with ionic and website is built with angular.
I noticed the one of Firebase Functions Pricing calculation include "Invocations". Is that Invocations means every time when I call the API equal to 1 Invocation? If yes, then the API might be abused by end user, since they able to view the website source and found the API.
I been searching solution in google, some of them suggest to enable authentication and cors, to avoid abuse of the usage. But authentication and cors still counting the Invocations right?
My code structure:
client call API by get/post method, pass user TOKEN that get from Firebase Authentication
request reach the Firebase Functions
server will check the preflight info by using CORS, as well as validate the TOKEN.
Return error if didn't pass on the (3), else proceed to execute the function.
So I assume if end user inspect my web source code and get the API URL, they can simply spam my API right? Then my bill will burst because of the load of Invocations.
If you suspect that your project is being abused, which is always possible, contact Firebase support to work towards a resolution.
Referring to - https://developers.google.com/actions/identity/oauth2-code-flow Im using Actions SDK which implies Im using Firebase Functions for the fulfillment handling.
Im storing information in Firebase against the UID I got from FirebaseUser.getUid() in an Android app. So far so good.
I've setup a mock OAuth2.0 server and this seems to be happy exchanging tokens.
However later on in the documentation it states:
"Your service's API endpoints use the access token to identify the user on whose behalf Google is making the API call, and to verify that Google has authorization to access the endpoint on the user's behalf."
My fulfillment however is in Firebase Functions. So...
Do I need to get my FirebaseFunction to get the User ID from the OAuth2.0 server? Do I need to setup an OAuth2.0 server in Firebase Functions? Where does the OAuth2.0 server sit? And how do I get my Firebase Function to get the same User ID as reported by Android?
First - you're starting with a small misconception. Actions on Google and the Actions SDK do not require Firebase Functions for fulfillment. Firebase Functions do make it easier - they provide the publicly accessible HTTPS endpoint that you need for a webhook, but if you have your own server (with valid SSL certificate) or if you want to use AWS Lambda or something similar, you can certainly do so. And if you want to use a language besides JavaScript, the JSON protocol used is documented (although sometimes not clearly).
To answer your questions:
If you need the UserID in your webhook, then yes, it needs some way to get that UserID given the access token it will be handed. But how you do this depends on how you implemented your OAuth server and token. For example:
If you used signed JTWs as your token, then the UserID is part of the JWT and all your webhook needs to do is extract this and verify the signature and timeframe on the JWT are valid. You don't need to contact any other server to do this.
If you're storing the tokens and corresponding user info in Firebase or in some other database or data store - just read the token from your webhook!
You certainly can create another HTTPS endpoint you can use to validate the token and get the info from it - this is what Google does, for example.
Your OAuth server does not need to live in Firebase Functions any more than your webhook does. It might be a good place for it to live (along with the authentication page on Firebase Hosting), but it isn't required.
Your OAuth server can sit... anywhere. Well, anywhere public on the Internet with a valid SSL certificate anyway.
This last point is exactly what account linking is all about. You need to make sure that, when they authenticate against your server, you get the UserID that is "reported by Android", whatever that means in your context (but see my update below). Once you have this UserID, you need to make sure it gets associated against any of the tokens that you issue for this user, and you need to provide a way for your service to get this UserID from the token.
How you do this is up to you, and depends on the rest of your architecture and what you're trying to do with it. The Google Assistant doesn't care - it has its own notion of a UserId which is separate from yours, so to identify the user with your UserId, you'll use the token that it hands you.
Update
You raise a good point in the comments about the statement "The user ID on Android devices will also be the same as the user ID on a Google Home". This is true, but talks about the anonymous cookie-like UserID that is available through the Assistant platform only (which is why it is in the section on Anonymous User Identity). It doesn't talk about any ID that you can get through other Android apps. To associate the ID you get through other apps to the Assistant's ID, you need to use Account Linking as described on the following page.
If all you need is a consistent way to track a user that visits your Action multiple times, and you want that to be consistent on any Assistant platform (Google Home, Assistant for Android, or Assistant for iOS), then you just need to use the UserID that is provided through the API/JSON. You don't need Account Linking or an OAuth server. But this is not a Google ID or the Firebase ID, it is a anonymous UserID that is valid on the Assistant platforms only (and then, only within certain conditions if the user does not reset it).
Update 2 To be clear about OAuth and JWTs:
You ask in the questions "Where else can I get the JWT?"
In short - you build it yourself.
Remember that, if you are providing an OAuth server, one of the things you need to do is to issue auth tokens and refresh tokens. Those tokens can be anything you want - the only criteria is that your webhook be able to take the token and, somehow, get the information it needs out of it that ties it to a user.
But you are responsible for putting that information in there in the first place.
So when the user logs in during account linking, you might use Firebase Authentication to log them in. Once you've done so, you can get a Firebase ID and/or a Google ID for them. (After all, they've logged into your OAuth web page - you have to know something about them.)
After they log in, you're redirecting them to some place Google has asked you to, and you're including a token as part of that. That token can be the JWT that you're creating, and in that JWT, you can include the ID information you have from their login.
(And, again... it doesn't have to be a JWT. It can be anything you want. The only requirement is that you be able to validate it and use it to get the information you need.)