I'm building a PWA with django/python on the server-side and vue on the client-side and want to use firebase as a database as well as make use of the firebase authentication.
After some thorough research I realised that I had to make a few choices.
Question 1: Authentication
I can do authentication on the client-side or server-side. Which one would be best (more secure) ?
Question 2: Database
In terms of CRUDS I am a bit conflicted. Do I write all my data to firestore from the client-side?
Do I rather use api's to communicate with my backend and then write data to firestore from the backend? What are the security implications of doing this?
Should I just use both in terms of context? If there are no security implications I would do my authentication client-side and my CRUDS from the server-side. I think I would also have to check authentication to write to the database from the backend.
Authentication of a user's credentials should always happen on a server, as it can't be securely done on the client's computer. What Firebase Authentication allows however, is that the authentication runs on Google's servers, while you control it from a simple client-side API call.
Related
One of my projects I have developed backend API using Django REST Framework and mobile app using React Native. I have done the following things:
When the users log in I store their username in local (mobile) database.
When users post data I send the username to server reading from local database along with the POST data.
I check whether the user is logged in or not using the username and then process the request.
My question is: am I doing it in the right way? If no then what are the right procedures to do this kind of authentication checking?
How are you authenticating your users? It sounds like your using sessions authentication which is fine as long as both ends are on the same doamin. Then you just use the request.user object as you normal would in a non-api setting. I would recommend using Django-rest-framework-Jwt https://github.com/GetBlimp/django-rest-framework-jwt Json Web Tokens do not require you to store a bunch of information in sessions on your server keeping things faster.
Here is a good example of implementing jwt if your interested https://www.techiediaries.com/django-rest-framework-jwt-tutorial/
There are multiple mobile apps.
I want people using one app to login with their same login credentials into all other apps.
What is the best approach to implement this?
I'm thinking to create a separate authorization server that will issue tokens/secrets on registering and logins. It will have a validation API that will be used by mobile app servers to validate requests.
There is a protocol for handling this called Central Authentication Service(http://www.jasig.org/cas), or CAS. CAS utilizes OAuth2 protocol to provide a secure way to manage a single sign on procedure -- users have a single login credential that is used via tokens and proxy tickets to authenticate the user across a variety of applications using a single CAS authentication server. This is a procedure the company I work for uses to authenticate users across multiple applications (we use Java with Spring Security and Spring CAS) however this summer we built out a proof of concept with Django and an internal company API in which we implemented CAS procedure with the Django application -- Django authenticated users via the CAS server we run and returned them as valid, authenticated Django users. To do this we used the django-cas middleware and custom backend library which can be found here: https://bitbucket.org/cpcc/django-cas/overview.
CAS is definitely the way to go if you're looking to handle user authentication with a single sign on across multiple applications -- it was the reason CAS was created in the first place. The learning curve with CAS can be a little steep but django-cas does a good enough job making it easy to get set up with CAS in the Django project.
First check if OAuth could be adapted to using this, that would save you a lot of work. Of course all the services and apps would have to talk to some backend network server to sync tokens issued to apps.
Half-secure/maybe-abusable solution: have symmetric cipher encrypted cookie that webpages (and apps?) hold and use it for authorization with different network services (which again have to verify cookie for authorization with authorization service that knows the passphrase used to encrypt the cookie)
I've used approach #2 on internal systems but I am not sure if it is advisable to use it in in the wild - this may pose some security risks.
The authentification method in every application connects to the same webservice for autentification.
I have a django project, in which i expose a few api endpoints (api endpoint = answers to get/post, returns json response, correct me if im wrong in my definition). Those endpoints are used by me on front end, like update counts or get updated content, or a myriad other things. I handle the representation logic on server side, in templates, and in some cases send a rendered to string template to the client.
So here are the questions im trying to answer:
Do i need to have some kind of authentication between the clients and the server?
Is django cross origin protection enough?
Where, in this picture, fit such packages like django-oauth-toolkit? And django-rest-framework?
if i don't add any authentication between clients and server, am i leaving my server open for attacks?
Furthermore, what goes for server-to-server connection? Both servers under my control.
I would strongly recommend using django-tastypie for server to client communication.
I have used it in numerous applications both server to server or server to client.
This allows you to apply the django security as well as some more logic regarding the authorization process.
It offers also out of the box:
throttling
serialization in json, xml, and other formats
authentication (basic, apikey, customized and other)
validation
authorization
pagination
caching
So, as an overall overview i would suggest on building on such a framework that would make your internal api more interoperable for future extensions and more secure.
To specifically now answer your question, i would never enable any server api without at least some basic authentication/authorization.
Hopefully i answer your questions on how you can deliver all of your above worries with a framework.
The django-rest-framework that you ask for, is also really advanced and easy to use, but i prefer tastypie for the reasons i explain.
I hope i helped a bit!
Here is the situation:
We use Flask for a website application development.Also on the website sever, we host a RESTful service. And we use Flask-login for as the authentication tool, for BOTH the web application access and the RESTful service (access the Restful service from browsers).
Later, we find that we need to, also, access the RESTful from client calls (python), so NO session and cookies etc. This gives us a headache regarding the current authentication of the RESTful service.
On the web, there exist whole bunch of ways to secure the RESTful service from client calls. But it seems no easy way for them to live together with our current Flask-login tool, such that we do not need to change our web application a lot.
So here are the question:
Is there a easy way(framework) so the RESTful services can support multiple authentication methods(protocols) at the same time. Is this even a good practice?
Many thanks!
So, you've officially bumped into one of the most difficult questions in modern web development (in my humble opinion): web authentication.
Here's the theory behind it (I'll answer your question in a moment).
When you're building complicated apps with more than a few users, particularly if you're building apps that have both a website AND an API service, you're always going to bump into authentication issues no matter what you're doing.
The ideal way to solve these problems is to have an independent auth service on your network. Some sort of internal API that EXCLUSIVELY handles user creation, editing, and deletion. There are a number of benefits to doing this:
You have a single authentication source that all of your application components can use: your website can use it to log people in behind the scenes, your API service can use it to authenticate API requests, etc.
You have a single service which can smartly managing user caching -- it's pretty dangerous to implement user caching all over the place (which is what typically happens when you're dealing with multiple authentication methods: you might cache users for the API service, but fail to cache them with the website, stuff like this causes problems).
You have a single service which can be scaled INDEPENDENTLY of your other components. Think about it this way: what piece of application data is accessed more than any other? In most applications, it's the user data. For every request user data will be needed, and this puts a strain on your database / cache / whatever you're doing. Having a single service which manages users makes it a lot nicer for you to scale this part of the application stack easily.
Overall, authentication is really hard.
For the past two years I've been the CTO at OpenCNAM, and we had the same issue (a website and API service). For us to handle authentication properly, we ended up building an internal authentication service like described above, then using Flask-Login to handle authenticating users via the website, and a custom method to authenticate users via the API (just an HTTP call to our auth service).
This worked really well for us, and allowed us to scale from thousands of requests to billions (by isolating each component in our stack, and focusing on user auth as a separate service).
Now, I wouldn't recommend this for apps that are very simple, or apps that don't have many users, because it's more hassle than it's worth.
If you're looking for a third party solution, Stormpath looks pretty promising (just google it).
Anyhow, hope that helps! Good luck.
I'm currently building a Python webapp on the Google App Engine and I want to expose various parts of my application via a JSON API. This API may be used in the form of a mobile client, or (for the purposes of testing) a headless Python script.
I need to be able to authenticate users before they perform operations on the API. I notice that the Users API does not support simple authentication [in the form of authenticate(username, password)] so merely sending the username/password to a URL and then later using some given token would not work.
Ultimately, I would like the application to use Facebook Connect in addition to its own logins.
Could somebody please suggest how is the best way to authenticate users in this situation, using a remote JSON API and the Google App Engine?
Cheers
You might want to check out the recently released oauth support. Failing that, you can implement your own authentication, for example by using simple or digest authentication.
Just for the record, I ended up going with the wonderful Tipfy framework in the end.