Like many, I'm in the process of creating a mobile application backed by a Django application and communicating via REST API. While the choice of the Django Rest Framework was easy, the choice of the additional component is tricky for me. I'm just discovering this ecosystem so it could be that I'm just looking at it the wrong way. These are my requirements:
The users should be able to create and edit an account (userena profile) via the mobile application, without necessarily using a third party (Facebook for example but it is planed for future feature). The registration process should include email verification.
The authentication process should be following OAuth, so the authentication module should provide a way to implement an OAuth provider.
I looked at this page but couldn't find any modules which provided all of these out of the box. Particularly I checked:
Djoser: Seems to provide registration (including email validation), token authentication but no OAuth.
django-rest-auth : Registration (including email verification), token authentication, 3rd part OAuth authentication but no custom OAuth provider implementation (?)
django-rest-framework-social-oauth2: OAuth provider, 3rd part OAuth authentication but no registration.
Did I misunderstand these modules or am I looking at it the wrong way? Otherwise, can the modules be mixed? Which would you advise?
Is there an easy way to take one module and, from there, add a custom implementation of the last functionality? (I saw post about implementing user registration manually but didn't find the email validation part...)
Thank you for your help.
Related
I am developing a mobile application for which Django rest framework provides the api.
I want a login system with username+password and google and facebook options
I have gone through the https://www.django-rest-framework.org/api-guide/authentication/
I mentions many third party packages in the end.
Can someone guide me, how to achieve my goal using which combination of third party packages.
I have used django-allauth previously but it has no rest support.
django-allauth has support in DRF also but it is used in django-rest-auth (latest fork dj-rest-auth).
I think that should be what you want, dj-rest-auth. That has all the features, like register, login, logout, email verification, password reset, social authentication.
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.
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 am trying to implement multiple login options in my ember-cli site (so you can authenticate via facebook, google, or my own oauth2 server). However, I'm a little at a loss as to the right way to accomplish this. As far as my research goes, I can see that there are multiple ways to do this using ember-simple-auth.
The first option is to simply use ember-simple-auth-oauth2, and create authenticators that extend that for each login method. This is a combination of the Authenticated Account and Multiple External Providers examples provided by ember-simple-auth. Obviously, this would mean writing all my authenticators myself including the ones for facebook/google.
The second option I see is to use ember-simple-auth-torii to authenticate each of my login methods, as in the Torii example provided by ember-simple-auth. However, I simply cannot find a good oauth2 example to help me create a provider for my custom oauth2 server. If anyone could help me out with this by showing me how to add a custom oauth2 provider to ember-simple-auth-torii, I would appreciate it.
Finally, the last option (that I can see) is a combination of the two above - Using ember-simple-auth-torii authenticators for google/facebook, and a ember-simple-auth-oauth2 authenticator for my own server. Obviously, I don't really want to rely on 2 separate ember-simple-auth packages, but if I have to I can (I'm assuming doing this would work?).
If anyone could pipe in on these methods or suggest a new one to allow me to do oauth2 authentication via facebook, google, and a custom server, I'd appreciate it.
Using both packages is the way to go. The Ember Simple Auth packages are built so that you always include the base package (ember-simple-auth) plus any additional packages for authentication strategies etc. that you want to use. If you e.g. want to use the OAuth 2.0 package to authenticate against your own server plus the torii package to authenticate against Facebook, Google+ etc. then you simply include both packages. There will also be no duplicate code that you're requiring as the common functionality is in the ember-simple-auth package and the ember-simple-auth-oauth2 as well as the ember-simple-auth-torii packages only include the code that's specific to the respective authentication strategy.
I'm using Django Social Auth for connect with Facebook issue and it works perfect. I have developed an API for my Django app with Django Rest Framework. But I'm confused about using Django Social Auth with Django Rest Framework for iOS devices.
I have searched 1, 2, 3 and 4 but they are generally with Angular.js. I'm not familiar with iOS development.
What is different between facebook connect with spa and a mobile device? * How could I use these packages together?
May I migrate from django-social-auth to python-social-auth?
You can now authenticate your users against your django-rest-framework with bearer tokens/third party access tokens from any python-social-auth backend (Facebook, Google, Github, etc.) using this library https://github.com/PhilipGarnero/django-rest-framework-social-oauth2
This module provides a python-social-auth and oauth2 support for django-rest-framework. Thus this saves you a lot of time to setup what is required to have your DRF with social authorization and to be OAuth2 secure.
I think that you can achieve that using django rest framework, django-rest-auth and allauth.
Those three work nice together.
With django rest framework you already familiar.
The allauth is responsible for the social authentication.
The django-rest-auth responsible for create the RESTful api for the social authentication, i.e. the connection between django-rest-framework and allauth.
It is recommended that you let python-social-auth handle the Facebook login for you, and instead you use another OAuth plugin for Django REST Framework to authenticate with Django. This has the added benefit of also supporting non-Facebook login through the standard Django authentication system.
I'm confused about using Django Social Auth with Django Rest Framework for ios devices.
I recently answered a similar question about implementing authentication with python-social-auth and Django REST Framework. It includes some important points to read about when implementing authentication using a third party along with some important notes about how you should not pass the third-party OAuth tokens back to your client.
How could I use these packages together?
While that answer specifically mentions using OAuth as the authentication method for the API that is behind python-social-auth, you can use other authentication methods that internally use Django authentication system, such as TokenAuthentication. In any case, you will end up proxying authentication between your front end application and your third party authentication provider, using your back end API.
What is different between facebook connect with spa and a mobile device?
Facebook provides direct integration with some mobile operating systems, most notably iOS and Android. This bypasses your API for authentication, and directly authenticates your mobile application with Facebook. Ideally, it would be authenticating your back end API instead of the mobile application. This may still be possible to do if you pass the access token back to your API manually, essentially doing the same thing that python-social-auth would be doing, but that could be risky and may not be worth the extra effort.
Facebook Connect (now known as just Facebook Login) works in a similar way to how Facebook integration works on mobile devices. The one difference that may work in your favor is that it's very easy to move from Facebook Login for single page apps, to an OAuth-based authentication pattern. This is documented in the Facebook developers documentation as "Manually Building a Login Flow" and is compatible with libraries that support OAuth-based login, like python-social-auth.
May I migrate from django-social-auth to python-social-auth?
This shouldn't be an issue anymore, as python-social-auth has effectively replaced django-social-auth.