Firebase Rest API mentions that we can pass CREDENTIAL to provide access to authenticated nodes. However I was not able to find documentation on where I can find these credential or generate these credential. Custom tokens generated using NodeJS firebase-admin client also don't work.
https://firebase.google.com/docs/database/rest/save-data
https://docs-examples.firebaseio.com/rest/saving-data/auth-example.json?auth=CREDENTIAL
If you scrolled down a little on the same page, you would find the answer:
In the following example we send a POST request with an auth parameter, where CREDENTIAL is either our Firebase app secret or an authentication token...
Firebase secrets are legacy credentials you can find/create under Project settings - Service Accounts in the Console. Using one as the auth parameter gives the caller administrative access.
Or you can use a service account to generate admin level access tokens instead of relying on the legacy secrets. See here for the Java implementation.
Or if you have an authenticated user – for example you're implementing an API a client apps call via HTTP, passing along their current access token –, you can use that token directly to impersonate the user.
The custom authentication tokens serve a completely different purpose and are part of a different sign in flow. Therefore they do nothing via the REST API.
Related
I am using firebase firestore as datastore for my web based application. The application has 2 different actors.
Supervisor: logs in via a common password set for all supervisors plus the ability to generate unique codes.
User: logs in via the unique code generated by the supervisor.
I am using cloud functions to do the heavy lifting for both actors. Now these functions are protected with cors and whitelist for origins.
I am trying to secure the routes created with cloud functions with a Auth Middleware relying on the concept of if the request is not from authenticated account or not.
I have created a email and password accounts for both actors for the frontend section of my application.
The question is if I am to go with firebase Auth api to get the refresh token and use it as jwt in the Middleware, will it be an issue since let's say 100 supervisor are connected and performing some tasks, and the same thing for the second actor ? Because after examining the refresh token it contains the uid of the account authenticated and using the same account for multiple connection is the blocking stone in this scenario.
the point of a token to be used in every operation is to validate the origin of the request
Firebase Authentication uses ID tokens to verify the user's identity, not the origin of requests. A malicious user in your scenario can get the credentials from the app, and use them in their own code - calling APIs on your Firebase project.
If you want to only allow calls from your own app, consider using the new App Check feature of Firebase.
I'm developing a web app (using Angular) which works with Firebase.
I installed the ngx-auth-firebaseui which is an easy to use library I used to perform user login. Since I need custom APIs I also developed an ExpressJs server that uses the Firebase Admin SDK.
I call ExpressJs APIs without any security for now (since I'm still in my local environment).
In order to use the Firebase Admin SDK, I followed the official docs, which say:
Once you have created a Firebase project, you can initialize the SDK with an authorization strategy that combines your service account file together with Google Application Default Credentials.
Firebase projects support Google service accounts, which you can use to call Firebase server APIs from your app server or trusted environment. If you're developing code locally or deploying your application on-premises, you can use credentials obtained via this service account to authorize server requests.
[...]
When authorizing via a service account, you have two choices for providing the credentials to your application. You can either set the GOOGLE_APPLICATION_CREDENTIALS environment variable, or you can explicitly pass the path to the service account key in code. The first option is more secure and is strongly recommended.
Locally I set the GOOGLE_APPLICATION_CREDENTIALS property and everything is okay. Does this also need to be set in the production environment or is there another method?
I would also like to use OAuth2 to secure communication between the web app and the server APIs, but I don't know how to integrate it within the authentication flow.
In addition, Firebase docs state:
The Admin SDKs also provide a credential which allows you to authenticate with a Google OAuth2 refresh token:
var refreshToken; // Get refresh token from OAuth2 flow
admin.initializeApp({
credential: admin.credential.refreshToken(refreshToken),
databaseURL: 'https://<DATABASE_NAME>.firebaseio.com'
});
but if I do this I receive the error:
.../node_modules/firebase-admin/lib/auth/credential.js:47
var tmp = from[key] || from[alt];
^
TypeError: Cannot read property 'clientId' of undefined
Question 1: Fireabase Admin SDK initialization -- How to handle locally vs. in production?
Answer: Using the Firebase Admin SDK requires initialization in the local development environment as well as the production server environment. In both environments, you may either set the GOOGLE_APPLICATION_CREDENTIALS environment variable, or you may explicitly pass the path to the service account key in code.
Question 2: How to use OAuth2 for secure communications between Wep App and Server APIs?
Answer: Verify Id Tokens
After a successful sign-in, send the user's ID token to your server using HTTPS. Then, on the server, verify the integrity and authenticity of the ID token and retrieve the uid from it. You can use the uid transmitted in this way to securely identify the currently signed-in user on your server.
Question 3: How to authenticate with a Google OAuth2 refresh token using the Firebase Admin SDK?
Answer from Manage User Sessions
Firebase Authentication sessions are long lived. Every time a user
signs in, the user credentials are sent to the Firebase Authentication
backend and exchanged for a Firebase ID token (a JWT) and refresh
token.
On the client (web app), the Firebase User has a refreshToken property to retrieve the current refresh token.
However, the standard approach to initialize the Admin SDK is to either set the GOOGLE_APPLICATION_CREDENTIALS environment variable or explicitly pass the path to the service account key in code.
I'm trying to build an IFTTT service and connect it to my Firebase backend.
I need to authenticate user as indicated in the IFTTT docs:
https://platform.ifttt.com/docs/api_reference#service-authentication
IFTTT’s protocol supports OAuth2 authentication, including support for
refresh tokens if so desired.
Your service API should use access tokens for authentication and as a
source of identity. A single access token should correspond to a
single user account or resource owner on your service.
If refresh tokens are used, they must be non-expiring. If refresh
tokens are not used, access tokens must be non-expiring.
But I can only get short-lived access tokens from Firebase it seems. Where can I get or how can I generate such tokens from the Firebase auth SDK?
Update in response to #FrankvanPuffelen:
I'll create an IFTTT service running on a Node server (possibly simply Cloud Functions) that will use the Firebase RTDB to send formatted HTTP request back to IFTTT. IFTTT requires me to authorize user accounts. Their required UX is something like this:
If an IFTTT user tries to use my service on the IFTTT website,
an auth dialog for my service pops up.
The user logs in and confirms IFTTT's access to their data on my service.
Some OAuth 2.0 tokens are exchanged.
IFTTT servers will periodically send requests (authentified with those tokens) on behalf of the user to my server.
Part of the question is: Can I use the Firebase Auth API to get those tokens, etc. or do I need to create a new OAuth 2.0 "layer" with my own generated tokens for IFTTT?
PS: I'm very new to OAuth, so it's all a bit confusing to me, sorry if the question isn't very clear.
So IFTTT calls Cloud Functions, which then calls Realtime Database, and you want to authentication the IFTT user with Realtime Database. Is that correct? If so, you can either use an OAuth2 token or create a Firebase Authentication session cookie.
Use an OAuth2 token
I did this not too long ago for accessing the Realtime Database from Google Apps Script. The requirements are relatively simple (once you know them):
The OAuth2 tokens must be requested with the correct scopes: https://www.googleapis.com/auth/userinfo.email and https://www.googleapis.com/auth/firebase.database.
The OAuth2 access token must be present in the request to Realtime Database.
The authenticated user must be at least an editor on the Firebase project. Note that this is not a Firebase Authentication user, but a Google user account.
Also see:
How to integrate Firebase into Google Apps Script without using (deprecated) database secret
Use a Firebase Authentication session cookie
You can also use a Firebase Authentication session cookie, which can be longer-lived (up to 2 weeks) than a regular Firebase Authentication ID token (up to an hour). You'll want to set up a Cloud Function for creating the session cookie, call that from IFTTT, and then pass the session cookie with the IFTTT request and along to the Realtime Database.
For more on this, see:
the Firebase documentation on managing session cookies.
I'm posting my solution here, this is a rough draft of what I did at at the time.
I'm using this auth method: My API has users with non-expiring OAuth2 access tokens and have an Express server responding at a Firebase HTTPS Cloud Function endpoint. Currently, at the prototyping stage, it generates fake tokens from the UID that are successfully accepted by IFTTT.
It's a redirect-heavy authentification flow based on this old IFTTT api example: https://github.com/IFTTT/connect_with_ifttt_auth_sample
Here's the gist of it:
Tokens and Auth Codes are just randomized and encrypted UIDs for now.
/oauth/authorize redirects to my app.
The app asks the user if they want to authorize IFTTT
The app redirects to /oauth/authorize_user
/oauth/authorize_user generates a user-specific code and redirects the user to IFTTT with this code
IFTTT asks /oauth/token to exchange the code for a Bearer tokens.
IFTTT can now make requests on behalf of this user with this bearer token.
Sample code here: https://gist.github.com/nathanvogel/15ed311258b91d7ec3d25f44047780e2
I want custom firebase authentication where a user manages the roles of subordinate users. I need guidance on understanding on how to implement my own backend authentication system. Everywhere the documentation keeps mentioning that 'send the username and password to your backend that will generate a custom token'. What is this backend? where do I pursue this? My knowledge domain is firebase, firebase functions, angular 2/4, ionic2 for this discussion... thanks
To use custom authentication, you need to create a JSON Web Token (JWT) on your existing backend server, after you have used your existing backend server to validate the username and password of the user (or however else your backend server validates your users).
To create that JWT, use the configuration described at https://firebase.google.com/docs/auth/admin/create-custom-tokens?authuser=0#create_custom_tokens_using_a_third-party_jwt_library
There is PHP and Ruby code available at that page, for anyone using a language that does not have an SDK available from Google, but which does have a JWT library available.
The JWT is signed with your private key, which you can obtain as indicated at https://firebase.google.com/docs/auth/admin/create-custom-tokens?authuser=0#create_custom_tokens_using_a_third-party_jwt_library
Although that page describes initializing the SDK, this section also has instructions for creating the private key for your service account using the Firebase console at https://console.firebase.google.com/u/0/project/_/settings/serviceaccounts/adminsdk
You will have to send the email password to the firebase sdk in using javascript in web then when the sdk success functions tell that the user has been authenticated the web page will send result to your backend server (can be nodejs or php etc) from there you have to manage your own database to handle all the role base access.
Firebase is basically authenticating the user for you and telling you that you can identify this user using the following userid and then build your own system.
Firebase has access rules but those you have to define first you cannot fully customize them for each user.
For password auth see this:
https://firebase.google.com/docs/auth/web/password-auth
An easy way to do custom auth with Firebase is using an external identity provider. Auth0 is an example of such a provider.
Guide:
https://shusson.info/post/using-firebase-and-auth0-together
code:
https://github.com/shusson/firebase-custom-auth
I've been reading through a bunch of documentation for using OAuth with Azure AD, but am still completely confused about how to properly implement things for my situation. Hopefully someone can steer me in the right direction.
I have created an ASP.NET Web API application that uses the EWS Managed API to access Exchange on behalf of different users. My application exposes endpoints such as /Mailbox/Messages and /Appointments with the intent that some front end web application will eventually use them to retrieve a user's emails and appointments. Currently the endpoints are working using basic http authentication, but I'd like to update them to use OAuth. The application has been registered in my Azure AD instance and I've configured it to require the "Access mailboxes as the signed-in user via Exchange Web Services" API permission.
Since the front end hasn't been implemented yet, I've been trying to test by manually calling the authentication endpoint. This prompts me to log in and provide consent. If I consent, I'm redirected to the callback URL that I provided when I registered the app with the authorization code contained in the query parameters. I'm still not quite sure how I'm supposed to be using this callback, but for the sake of testing I currently have the callback redeem the authorization code for an access token. This is done by calling the AcquireTokenByAuthorizationCode method on an instance of the AuthenticationContext class and providing my application's id and secret. Again, just for the sake of testing I return the access token to the browser. I can then call my aforementioned endpoints (after some modifications) with this access token and get the emails for the user. I'm guessing much of this is not the correct way to be doing things.
Some of my points of confusion:
What should the callback that I registered in Azure AD actually be doing when it gets the authorization code? Is this intended for a different type of application? Perhaps one that isn't just playing the role of a middle man.
I'm trying to make my application somewhat RESTful, so I don't want to have to maintain the access tokens on my end between requests. As such, does it make sense for my endpoints to expect that the access token be provided in the authentication header for each request? If so, does that mean the front end application should be responsible acquiring the access token and passing it to me?
Being completely new to OAuth and Azure, I'm not sure if any other details are pertinent, but I can provide more information as needed.
What you are implementing is this scenario: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-authentication-scenarios#daemon-or-server-application-to-web-api
Here's how it works:
Your client app redirects the user to sign in at the authorization endpoint
Your client app gets back an authorization code (if using the auth code grant flow, there are others)
The client app exchanges the code for an access token for your API app
It will need to provide its client id and secret along with the code and the API's resource URI to get it
The client app calls to your API app, passing the access token in the Authorization header
Your API app then validates the access token, and requests for another access token from Azure AD for the Exchange API
It will pass the access token sent by the client app, along with its client id and secret and the Exchange API's resource URI to Azure AD
Your API app receives an access token so you can call to the Exchange API as the user
And to answer your two questions:
Authorization code flow is not used with APIs, only with apps that have a user signing in, thus the redirect URL is basically never used
Your API can and must expect and authenticate the access token for it to be in every request. But the access token it uses to call the Exchange API can and should be cached on the API's side. This is provided out-of-the-box with ADAL, though the tokens are only in memory.