I am developing a web-app that uses Firebase (web client JavaScript). For authentication, I am trying to implement sendSignInLinkToEmail to sign in a user. But, I’m facing an issue.
Suppose the user is trying to login on his desktop and uses his phone for verification, I want to redirect him to the dashboard on the desktop after verification. How can I do this?
Ref: https://firebase.google.com/docs/auth/web/email-link-auth
const actionCodeSettings = { url: 'dashboardURL', handleCodeInApp: true }
This redirects to the dashboardURL on the phone (device used for verification), but I want to redirect on the desktop (device that initiated the login flow).
Firebase Authentication does not natively support this. You'll be logged in on the device where you open the link. You'll have to build this functionality yourself and a simpler approach would be to use Cloud Functions and Realtime Database.
The flow would be like:
User clicks on "send link" and is redirected to a page that listens for updates in realtime database at a key (randomly generated session ID depending on your requirements).
When a logs in on another device, call a Cloud Function that generates a custom token for signing in and then emit it the first device via realtime database.
Log the user in with signInWithCustomToken().
This is just a simplified version of a system that might use websockets, session Ids and additional factors for security. You can also use Firebase Anonymous authentication to ensure only that user can this token using security rules.
Related
I am trying to use a 6 digit code to log-in a user.
The code is available for 20 seconds and is unique to every user.
Briefly explained:
User is already logged in on a mobile app
User press the button "Get Unique Code"
Then, user enter the code on a WebPage on his PC
If the code is correct, show data for that user
What am I asking is if there is way to properly authenticate the user who introduces that code correctly given that I have the userID and all the informations about the user?
I can try and "fake log-in" (display all the information for that user when the code is correct) but there are some issues with this and I would like to avoid it.
I am using Firebase Authentication and Firebase Firestore. JavaScript is used for Web.
You can implement any authentication scheme you want by creating a custom provider for Firebase Authentication.
See Authenticate with Firebase in JavaScript Using a Custom Authentication System and Creating Custom Tokens with the Admin SDK.
In this flow you:
Sign in the users yourself.
Create a custom token for those users in a trusted environment, such as a server you control, or Cloud Functions.
Pass that custom token to Firebase Authentication, which can then use it to identify the user, and secure access to Firestore, Storage, and Realtime Database.
I want to allow users to sign in/up via GitHub and via email/password using firebase.
In the server side, I implemented using the firebase_admin SDK, the email/password like it:
user = auth.create_user(
uid=submission["id"], // customized id
email=submission["email"],
password=submission["pass"],
display_name=submission["name"] + " " + submission["lastName"])
It worked fine, but I want to get the same result when signing up via GitHub. That is, I want to be able to set my own uid. Notice that I want the code being mostly on the server side. And I want the user to click on the same button to either sign in or sign up.
I actually managed to authenticate the user with a custom uid from the server side using the next code taken from the firebase documentation:
provider_data=[ # user with Google provider
auth.UserProvider(
uid='google-uid',
...
But I don't understand how to sign in once the authentication is over. Is the sign in code should be in the client side?
Signing in always happens on the client, and never on the server. All you can do with the Firebase Admin SDK is create, delete, and modify accounts. The end user must provide credentials for that account when signing in to the client app.
I've a requirement to integrate Auth0 in our project (Reactjs/Hapijs/MySQL). I checked the documentation and they have many examples and that is great, however, I can't find any related to how exactly do I use my existing user database.
In my application I have users and those users can have one or more projects. With the authorization that we currently use, a user logs in, I check what projects does he own and send it to the React application.
I am missing a document that explains me how to use Auth0 and still be able to check in my database what projects user owns.
My idea on how that should work (I might be wrong):
User sends username and password to our server
Our server makes request to Auth0 (with provided credentials)
Auth0 replies back to our server with some token
We look in users table in our database and try to verify the existence of that user
If it is a match then we simply look (as we already do) for user projects.
Is this how it is supposed to work?
There are a few options available for scenarios where you want to integrate Auth0 with applications that already have existing user databases. You can either:
continue to use your existing store
progressively migrate your users from your custom store to the Auth0 store
You don't mention it explicitly, but judging from your expected flow it seems you would be wanting to implement the first option. There is specific documentation that you can follow that explain how you can setup your custom database connection, see Authenticate Users with Username and Password using a Custom Database. It mentions MySQL, but others database servers are supported and there are many templates that will allow you to quickly setup things.
When you complete this the final flow will be the following:
Using either Auth0 authentication libraries (Lock) or your custom UI you'll ask the user for their credentials
Either Lock or your custom UI submits the credentials to Auth0 authentication API
Auth0 authentication API validates the credentials by calling scripts that execute against your custom database (these scripts were provided by you when you configured the database connection)
If the credentials are valid the Authentication API will return a token to the calling application that will have user information and proves the users is who he say he is.
The scripts you need to provide are the following, but only one is mandatory:
Login script (executed each time a user attempts to login) (mandatory)
Create user script
Verify email script
Change password script
Delete user script
The optional scripts are only required when you want to provide the associated functionality through Auth0 libraries, if only need the login to work then you can skip them. The login script, in the case of a valid user, is also where you return the profile information of the user, for example, you could in theory include their owned projects in the user profile.
I want to create a client-side (server-less) application using the AWS SDK for JavaScript in the Browser. All intended users of the tool have individual IAM users and access to the AWS Web Console.
I want all API calls to be executed in the context of individual IAM users, so they are subject to each user's individual permissions, and so that I can see who did what in CloudTrail.
Since no kind of browser local storage should be trusted with persistent credentials, I cannot simply let the user enter his secret access key once and keep it.
However I guess I could request the user's access key id and secret access key on the beginning of each session, then call STS GetSessionToken with it, and only store the resulting temporary security credentials in the session storage and use that for all following SDK usage.
Of course it would be much nicer for users to be able to log in with their IAM user and password instead of their long and cryptic access key (think of mobile devices...).
Is there any kind of federated login option for IAM users (redirecting them to the AWS IAM login page), or a way to call the STS API with username and password?
Ideally, what you want is login via IAM user/password combination. As far as I am aware (and also see this) there is no standard way of doing this.
In one of my projects, I've simulated online login using HTTP client. If you can get the session token with that, that could work for you. But it does not support MFA, and is relying on the internals of the AWS authentication implementation which might change without warnings.
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.