Actually i want do it in this way when user sign up with fake email. user can't verify this email.So the email should automatically deleted from firebase authentication after fixed time.
There is nothing built into Firebase Authentication to auto-delete accounts like that. I'd also consider what you actually gain by such functionality, as the user can just recreate their Firebase Authentication account by calling the same API again.
You'll typically either want to:
disable their account, which prevents them from signing in/signing up with it. This can be done through the Firebase Admin SDK, by first getting a list of all users, and then disabling the relevant ones.
only grant them access to your back-end services if they've verified their email address (within a certain amount of time). How to do this depends on your backend services though.
Related
Iam working on a flutter mobile application where i use Google SignIn for Auth, is there a way to authorize users with existing account only?
Prevent users from creating new accounts? I've looked for the same thing without finding a way to do this with any Firebase project setting.
The solution, I believe, is consider the difference between authentication and authorization. Firebase's Authentication service is aptly named. It does authentication
- validates that a user is actually who they claim to be. It does not do authorization - control what actions authenticated users are allowed to perform or what data they can access within an application. App developers have to be responsible for managing user authorization.
One way to do this is to maintain a collection of "authorized users" in Firestore, for example. When a user authenticates, your app would perform a lookup to see if the current user is actually authorized or not. Security rules can be written for Firestore and Firebase Cloud Storage to also validate that the current user is in the "authorized users" collection before allowing access to data. But this requires extra data queries to obtain this authorization info.
The authorization method I prefer is to use Custom Claims which can be assigned using the Firebase Admin library. A custom claim can be added to an existing user account that can act as a flag indicating what type of authorization they're granted. Front-end code can check the authentication token they've been issued for the custom claim to determine the authorization they've been granted. Server-side code and security rules can also check for those required custom claims within submitted requests.
Realistically, any application you build where different users might have different levels of access will require you to deal with authorization. I believe that assigning carefully thought-out custom claims is the best solution.
I'm using Keycloak for Identity Brokering through Google, Microsoft, etc. But Keycloak only allows one email per user. So the user can be authenticated only through one of the social login options (Google if gmail is added as user's email address, etc.). Is there any way to include more than one email per user, or any other workaround?
EDIT: (Editing based on comments to make scenario more clear)
In my scenario, I'm using a federated user store which contains a large number of users and and I need Keycloak to access all the emails linked to a user when that user is logging in using Google,Azure,etc. because Keycloak is using the email as the unique identifier for the authentication response from the social login provider. Without having the required email as the main email, Keycloak won't allow that user to log in through social IdP
Although, Keycloak emphasises on keeping a unique email,but there are certain scenarios where you may want to keep , say, secondary email.
This can be achieved in a couple of steps:
1. Add a custom attribute for secondary email in user like this:
2. Next , in your client create attribute mapper like this:
When I generated the token after above configuration, the new attribute was avialble in token. You can use this attribute in your app as you desire.
Parsed JWT:
I figured out the best way to deal with this is through the custom user provider (federated user store). Even though we can't add multiple emails per user through the Keycloak admin console, we can write the user provider in such a way that it can get all the emails linked to a user from our database and assign them to the email attribute of each user. Once this is done, all the emails will appear on the admin console as well.
For the social login to recognize those emails, we have to get all the emails linked to a user in the provider to an array and iterate through it until the authentication is complete. This would help to create the social login link to the user through First Login Broker authentication flow.
This is a crude way to approach this, but nevertheless it works!
Many mobile apps require user login. That's why Ionic launched their Auth service (https://docs.ionic.io/services/auth/). I can create users via the Auth service itself or via the Ionic API. I also can save custom data for each user. Very nice is also that I can sen targeted push notifications to my users. Seems like a nice out-of-the-box solution.
But most of the time apps have more complex logic (user can post something, user can order something, make a payment, ...). The simple user with some atributes from Ionic does not help much in those cases.
So I need to authorize the users not only inside the app but also against some custom API. And this is where my questions come up...what's the best way to do this?
Some things that came to my mind:
When creating the user in Ionic, also create the same user with the same email and password in my API. So I can make authorized requests. But this does not user any token and I would have to pass my password in every request, also I am worried about data consistency. What if the user changes its password?
Use the internal Ionic user ID, create one global token and use user ID and global token to authenticate the user in my API. But is this secure?
Another worry in my mind: If I save user name, email etc in the Ionic Auth system I would have to access it via their API every time I need it in my own system. For example: A user orders a product in the app. Then my system needs to send out a confirmation to the user. I would have to access the Ionic API to know that users email...and so own.
I think this is all confusing.
Is Ionic Auth not made for those situation? Then, I don't see what it's made for at all...
Is ionic Auth just not there yet...?
Am I just not getting it?
If I add authentication in Azure Mobile Service with Google as the provider, I go and create an app, get the app_id and secret and plug it in. Great, now users can authenticate with google and get a user token. Now they are considered an "authenticated user" wrt the table permissions.
However, I don't want to authorize everyone with a google account access to my API. Is it possible to limit this to a list of known users? Must I check every request for specific user ids?
Perhaps social login is not the best choice here and I should use something else like Azure AD?
We added custom authentication provider to wams and synchronize the social account with "our" user-account that is stored in the database. For protected web api methods a user account needs to be activated first. You have to check manually whether an account is activated/ high privileged or not and return the result or unauthorized status code.
I decided to use Azure Active Directory to solve this problem. This way, I can create users in Azure AD but not have to manage users myself in the back end. With this choice I am still able to chose the only authenticated users permission level without having to check on every rest endpoint that the authentication users is one of the ones I want to grant access to.
I'd like to create this simple model:
user registers and Firebase stores email & password
user pays with PayPal to access protected content
Firebase gets notified by PayPal the user has paid & logs this
paying user logs in with his credentials & Firebase authorizes access to the protected content; non-paying users are denied access
What is the bare minimum amount of functionality needed to leverage Firebase's backend and make this work?
Depends on your exact requirements (ie, are 5 or 15 minute delays acceptable) but you can get started super quickly using Zapier
https://zapier.com/zapbook/firebase/paypal/
You would setup the zap using your secret firebase and paypal keys, setting the zap to update a property on the user's profile (be sure to use Firebase security rules to limit write access to that property) which says they have paid.