Im develop a app. I'm using firebase and flutter.
But now i would change from firebase to my own database (node.js).
Here my question:
Is it possible to use the firebase user authentication with my own database?
Or need i host a own smpt server to send the verification emails?
Is it possible to 'keep the user login' without firebase?
How i can do that?
If you have any question to me feel free to ask me.
Many thx (:
Yes, you can use Firebase Authentication with your own database, or other backend service. You will need to implement your own server-side code that verifies the ID token from the client, and then ensures that the client is authorized to perform the operations it requests.
Related
I am trying to integrate Microsoft Graph API with my Django backend application. I want to be able to read, manage and send emails on behalf of users.
The frontend is built with React
My issue now is how the authorization flow will work. I want users to authorize the app(prolly using Oauth) on the frontend after which I will get some kind of access code that I can save on the backend and subsequently use to make requests to the graph APIs on the user's behalf
Pls, how do I achieve this flow ??
Any help will be appreciated. I have been scrambling through the docs all day, need someone to point me in the right direction
Get access on behalf of a user:
Follow this documentation for more information: https://learn.microsoft.com/en-us/graph/auth-v2-user
I am rather new to app development but I have the front end sign-up and sign-in form ready to go in react native. I want to send this data from the client to my AWS server to authenticate and create session tokens for each user. Online all I can find is using Cognito with Amplify. This is not a problem, although I want to be able to access the session token on both the client AND server side. Is this possible with Amplify?
I've used express as a react server on AWS in the past for Websockets, Routes and other fun stuff and was hoping to use that again since I am familiar with handling the backend logic that way. There, I'm assuming I would receive session tokens from clients and compare with what Cognito/Amplify has on record. If the session token matches, then dish out appropriate resources like an image, string, video etc. from other AWS services (e.g. S3, DynamoDB). Express would allow me to create custom API Routes/URLs in this way.
Does any of this sound like a good plan or even feasible? Are there other easier ways of achieving this? Its hard to sift through all the documentation they offer. Please let me know! Thanks in advance :)
You can use Auth. currentAuthenticatedUser after the sign up process to get session auth token and save it in the front end. If you are going to send it to the backend you will need to make a PostConfirmation function in Cognito get the access token and send it to your backend.
The best way to do it its handle everything with Amplify, if you are more comfortable with Express I recommend you to create a Rest API in Amplify. They will handle everything related with the resources access.
I recommend you to watch this Youtube Channel. He has very neat tutorials. https://www.youtube.com/user/boyindasouth
im maintaining an older react web-app that uses a firebase realtime-database to store its data. I want to restrict the access to the database, so that only my react app can read from and write into the database. Is there a way to set up an admin-like login (kinda like with sql-databases) to authenticate my application?
I don't want to authenticate other users or enable them to register, I just want to ensure that only the web-app can edit and modify the database.
I've tried to experiment with the firebase authentication-methods but they don't seem to be what im looking for.
Thanks in advance!
I don't want to authenticate other users or enable them to register, I just want to ensure that only the web-app can edit and modify the database.
That's not possible. The only way to control access to a Realtime Database instance (while allowing direct access from web and mobile clients) is using Firebase Authentication to identify users, in combination with security rules that determine which users can access which data. Otherwise, anyone with an internet connection will be able to read or write the database.
I created this web app completely in go-lang, which uses Google Drive API to authenticate users. Once user authenticated, it saves the token in a <user-email>_token.json file so the app can operate for 24 hours without the users involvement. It works fine. But now I want to separate the front-end from (Go-Lang)back-end and convert it to AngularJS.
So I have this problem with authentication. Because I should keep the authentication in server-side. But then how would Angular know that the user is authenticated or not? Because I cannot use sessions.
Should I need to use JWT to this? If it is, then how should I do it?
Your token does not have to be on the server side.
Why? Because if you have many clients connected to your server, it would mean that all of these clients are sharing the same token and therefore have access to the Google Drive linked to this token. It does not make sense.
The token has to be on the client side. You should save the token as a cookie, maybe by using JWT, I let you read the documentation of JWT to know why it would be interesting to use it in your case or not.
Then on your Angular, you have to say something like "hey, this client has a cookie called "my-google-drive-token", let's check if that is a good one... Mmmmh, okay seems to be good, I display the Google Drive content".
Think about using good practices about security (using an encrypted token in your cookie, making the connection between the front and the back safe, keep your API key safe...).
Your backend is only a gateway between your front-end and the Google Drive API.
Also, check the usefulness of your server. I think that in your case, a simple frontend connected to the Google API is enough.
Im searching solution about authentication.
I found IdentityServer and Im trying understand how it works.
In my case I need to check user exist in another app.
I have old project created in asp.net web froms and this project have a users collection stored in db.
Now I must create client who will be call to WebApi and in this WebApi I need to authenticate user. I want to do this using IdentityServer4. Can I in IdentityServer call to my old application or db this application and check user by custom method?
In future I want connect another application to IdentityServer and this new application should have users in IdentityServer, so I will be have two places where I will have users for two application. I need to be sure I can check user exist in this two ways.
When request will be form new app IdentityServer should check user in his db and if request is from client who will be call to old app should check this user in external app(db).
Example call:
enter image description here
I dont know I good understand idea of IdentityServer, but generaly I think this is not good solution for my case...For now I understand I can store users in database but only with Asp.Identity in IdentityServer.
What do you think about this case ?
In future I want connect another application to IdentityServer and this new application should have users in IdentityServer, so I will be have two places where I will have users for two application. I need to be sure I can check user exist in this two ways.
When request will be from new app, IdentityServer should check user in his db and if request is from client who will be call to old app, should check this user in external app(db).
The short answer is that IdentityServer4 is just an implementation of the OpenID Connect protocol and the persistence and authentication of users is entirely customisable so you're free to implement that any way you like.
As for where to keep your users - that will depend on your problem domain and business rules but I'd probably try and avoid using multiple DBs if possible and instead migrate existing users from legacy applications to your identity service's own store and take care to only bring over identity and authentication information and not access control/authorization information. i.e. keep the authorization logic in your client applications and APIs.