I have an application that will use flask and mongodb; I will probably host it on rackspace.
I need to understand how flask authenticating works. I have not found much information on the subject. Is there a complete tutorial on how to roll your own solution? If not, I certainly would like to hear some thoughts on how you would approach it for a a flask app.
Big PS:
I just thought about it. I also need to open a real API. A part of that API will be used for AJAX on the front end. How do i secure that part of the app?
Can anyone explain API auth requests?
I would suggest using the flask-login extension, it makes session management really easy to add to your flask application, and provides a nice documentation which covers in details every aspect of the extension.
I don't think that flask has any authentication built-in, only support for tracking sessions.
Here are some snippets for basic HTTP authentication and authentication with some third-party providers. Otherwise you will need to roll your own or use a framework that has this baked in (like Django)
Here is a discussion thread on this topic with a useful link
Flask-Login doesn't, technically, do authentication - it does session management, leaving the (tricky to securely implement) authentication details to you. Something like Flask-Security actually implements both session management and authentication (also nice-to-haves like password recovery/reset and the like), at the cost of having to have explicit support for your database.
Related
I am building flask rest and planning to use flask-restful. I am familiar with flask login, but understand that with restful I need jwt.How to implement authentication? with flask-jwt or flask-jwt-extended? Also I am not using blueprints for this small project.I need to authenticate my routes(that are actually class Resource).
Thank you
If you look at the commits on the Github pages of both Flask-JWT and Flask-JWT-Extended, I believe it's safe to say that Flask-JWT was abandoned. I would advise to go for Flask-JWT-Extended, it also has more features (like refresh tokens).
Also mentioned in this post.
I'm new to Okta and I'm having a tough time wrapping my head around what I need to do in order to authenticate users.
I'm writing a web portal for a company that already uses Okta internally.
They have requested that I use Okta to authenticate users. That is the only Okta integration requirement.
The portal uses vanilla JS/CSS/HTML5 on the front end, and a custom Python api layer and Python back end for serving data.
I've read through the guide over at http://developer.okta.com/docs/guides/pysaml2.html and I can't help but think this seems like overkill to simply authenticate users.
I saw that when I created a sample app that I could create the app with Secure Web Authentication rather than SAML. Is that advisable in my case? Do we need to use SAML?
If SAML is the correct approach, I'm feeling a bit lost after reading through the documentation about where to even begin. The app itself isn't really a Python app, although Python is used.
I have the Okta app created. I have the custom web app created with a custom Python backend and API layer.
Any tips on how to connect the two in order to authenticate users?
Have you seen this: http://developer.okta.com/docs/guides/okta_sign-in_widget
Seems most appropriate to your situation.
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 am considering a 3rd part Authentication system for logging in (new/old) users. Much like how StackOverflow authenticates it's users. This scheme is good as it frees me from doing authentication from my side. I need this -
Login using Google, Facebook, Twitter, Yahoo, OpenID Authentication Systems.
Provide the same user logged in functionality as the default django auth system i.e. #login_required decorators should work
There seem to be some number of Django-apps out there which claim to solve this problem. Which ones are good?
Ex. Django-SocialAuth, django-openid-auth
For an all-in-one solution, I had good results with django-socialregistration. It has auth backends for Twitter, Facebook and OpenID (Google, Yahoo!, ...).
Another possibility would be JanRain Engage (formerly RPX) which provides a single point of authentication for all the major authentication providers. There's a 3rd party django app for it, but I can't say anything about its quality.
If you want something simple try this
those are actually auth backends.
In other words, you're still using django.contrib.auth - you're just loading an extension to it.
Auth backends are pretty easy to write, so I would just take a look at the docs and then see if the code looks like something you'd be comfortable working on (for each candidate for a backend).
If you're afraid to change your codebase, you're in trouble.