I've been suggested to use token-based authentication, in order to secure my webservices, and to create another filter that verifies tokens, apart from auth. The idea is to use the auth filter for log-in, which I have already done in the backend, and to create a new filter for webservices. Could someone recommend a good tutorial on how to do this, or give me an example?
This is what i use, specifically for mobile app web services:
https://github.com/lucadegasperi/oauth2-server-laravel
Which is an OAuth2 server package for Laravel. It includes all you need to authenticate, generate / validate tokens, throttle, and protect your endpoints.
The OAuth2 spec has a bit of a learning curve, but is definitely worth it.
Related
I am building a web app with a Django backend and React/Redux frontend running on separate servers. I have begun to try and start working on authentication and I cannot find a tutorial that suits my needs. Every tutorial either uses deprecated modules like drf-jwt (as opposed to simple-jwt) or has a simple mono-server that houses both the backend and the frontend in one directory. The former is useless and I do not want to do the latter as I like having the two separate servers for when I move on to deployment. Now can someone direct me to a good source of knowledge for getting this done? It doesn't have to be a tutorial it can be anything. I am really lost and I do not know how to begin.
you can use 3rd party packages djoser: Provides a set of views to handle basic actions such as registration, login, logout, password reset and account activation. for more information: https://pypi.org/project/djoser/
I'm using token authentication from Django Rest Framework so, after a login/password verification, the token on response can be used on any DRF endpoint.
I am creating a Flutter project with Django + Django Rest framework as the backend. I want to add user authentication to the app.
I found some ways to achieve that such as Session authentication or token authentication. According to this article, if we want to add user authentication for mobile-based apps, it is best to use token authentication since session authentication is not suited for mobile phones.
Is it really best to use token authentication for mobile-based apps instead of session authentication?
Yes, token is best for mobile client.
Mobile and cookies are not good friends ;)
Token authentication work well for multiple device connection with same account and it's easier to store token.
It's stateless and work without cookies.
I have worked on two projects with Django and flutter.
I think for android or ios projects, token based authentication is best to go with because they are stateless and you can easily manage user roles and permissions for the application too.
From security point of view, it's also better because there's no possibility of creating a CSRF request when you app is using tokens.
Cookies don't fit much with other platform than a browser.
I am developing Django(Server) with React(Web Client).
And I want to use facebook social login.
I knew that client is public client, server is confidential. So I want to use authentication code grant way for authenticating user.
So I find out the way but there is no way to implement that. All the python oauth2 library limplements is just for django server side rendering.(Django Server + Web client).
So I confused about I am wrong or just the others just did not make the grant way.
When you use DRF(Server API) + React(public Web Client),
how do you implement for OAuth2 social login?
I wonder that. please give me some advise to me.
Thanks.
Let's start from basics, people usually split frontend and backend to improve the production speed as frontend and backend can be developed by two separate teams. But in order for the frontend and backend to work together, there needs to be a connection interface, an API.
React is a frontend that runs in the browser, so in order to talk to the server, it uses a REST protocol.
As the backend in this scenario is Django we use DRF as React uses REST API. DRF provides easy flexible pre-built packages to carry out this communication job between server and client.
Now the authenticator for web login you choose to be Facebook hence you will get the identity token from facebook, which will correspond to the rows in the Django User table which will give you access to the user's data in Django.
You don't need to do everything at once, you need to first implement the Facebook social auth and after test(test using postman app) only think about connecting React
A good place to start is this DRF documentation, look into Social OAuth2
https://www.django-rest-framework.org/api-guide/authentication/#django-oauth-toolkit
Looking for insight into a use case in Django REST Framework (DRF) and supporting customer defined authentication method: TokenAuthentication (by default), SAML 2.0 SSO, OAuth2 federated login. The method is set per customer account. I know I would enable SAML 2.0 support for all users in DRF, but I don't see how to have each user account in our software use their own Auth engine, method and settings. DRF seems to want an all or nothing configuration.
I'm aware of both django-saml2-auth plugin and this StackOverflow question SAML SSO Authentication with Django REST Framework
django-saml2-auth is a great plugin and is likely involved in the solution, but I see no examples of how to have multiple different authentication methods on a per account in your app.
More details:
I want to allow a per customer method of supporting account settings enabling the option to select one of multiple authenticate methods such as TokenAuthentication (by default), or SSO and providing SAML 2.0 or Oauth2 setting. Every account could select from the enabled methods. DRF seems to expect a single authentication provider to be enabled. Not grokking how to do this in this framework yet. Currently using TokenAuthentication as the default authentication system. TokenAuthentication would remain the default provider for most accounts. I need to be able to allow more sophisticated enterprise customers to switch authentication methodology. That's the challenge. Adding SAML2 is simple. Using OAuth2 is simple. Allow any of them to be chosen by accounts, with each account having their own authentication workflow. This is quite a different requirement than the use case that django-saml2-auth solves. That plugin may be involved in the solution, but the limitation here seems to be the model DRF uses to define the authentication provider. I've scanned the DRF, and django-saml2-auth docs, code and examples. Nothing I've seen anticipates this.
My current working theory is that I could make it possible with a little creative thinking. Perhaps there's a different URL mapping that utilizes different login/authentication method. The logged in data token that must be provided in subsequent calls could have a custom validation method that works with all supported protocols without large new blocks of code. So my instinct is the problem is mapping the login process to something that is not universal and requires some type of pre-fetching of account configuration. My proposed solution there is in the login URL for the enterprise cases. But still DRF seems to still be lacking a method for defining the authentication process per each account. Say I use SAML2 through Okta, You use OneLogin, Another person uses an OAuth2 provider, and most customers use the default native TokenAuthentication. We're all users in the same DRF app. But there isn't a way I see to define authentication engine based on account.
I know there is a possible brute force method of customizing the method being invoked to perform the login action that could be non-standard, query to configuration for a customer, then use either native or a federated identity provider. However, I'm hoping there are more DRF grokking folks that know of other strategies to enable this functionality.
I understand that there is a chicken and egg syndrome in that until you know something about the customer making the request you won't know what their configuration is. We will most likely need to support a different login URL for enterprise customers who enable SAML. That way you could load the customer's configuration. Perhaps we would do something like use a URL like so: www.myproduct/login/the_customer_company. Being new to Django REST Framework I am not super clear how to wire up different methods of authentication within the Django settings.py or urls.py? The default new user configuration would remain TokenAuthentication based but on request a customer could configure SAML and use a different URL including the company name. Hopefully my question is clear. I see how to configure DRF to use SAML SSO instead of TokenAuthentication, but I want to allow customer configured settings.
DRF and the django-saml2-auth approaches seem to be "all or nothing" and provide a single authentication provider mapping for the application. I would love to be wrong about that limitation!
One option to achieve this would be to use an Identity Provider (IdP) that can act as an identity broker, for example Keycloak. Configured this way, your Django app would be configured for SAML authentication with the single IdP. The IdP can then be configured for whatever upstream SAML / OAuth identity providers it supports depending on the customer requirements.
How you get the users to the right upstream identity provider and still have a good user experience would have a few options. The two most obvious ones would be to either configure a custom URL for each user group, and have that URL redirect to the correct IdP landing page when logging on. Alternately you could perhaps have a login page on the Django site that asked for their login / email address (without password), and when they entered that it looked up the IdP URL associated with that user and then to sent them to the right place.
While this is not a Django module / code solution for the problem, it simplifies the authentication on the Django side, and decouples the authentication to an external service specifically designed to do auth, providing the app with more flexibility (and probably more security).
I'm working on a service with REST-api implemented on django rest framework. I'l have web-site with frontend on javascript (possibly, SPA on Knockout), android and iOS apps, which all will be using this API. What is the best way to handle authentication in this case?
I'v read a lot on JWT-tokens (not my case, i must have ability to revoke auth for particular user at any time), sessions (already using django), storing tokens in localStorage and so on.
Should I have one type (tokens?) for all? Or is it normal, to use cookie-based session auth for web and tokens for mobile apps? If web also goes with tokens, where is the best way to store them: cookies or localStorage?
It's perfectly fine to use many authentication methods.
For web app this can be session base auth, assuming that you run it on the same domain. For mobile app you use tokens. DRF will check all methods defined here.
Therefore, remember to enable/disable correct ones.