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.
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.
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).
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.
Just to clarify my understanding of what Torii provides for client side static apps:
OAuth 2.0's Implicit Grant workflow is the only OAuth workflow which works in client side static apps.
Torii only supports this via torii/providers/oauth2-bearer, which returns tokens not codes.
If 1. and 2. are true, then I suppose all client side static apps which use Torii would only use the oauth2-bearer approach. The rest of the providers in Torii, like stripe-connect etc. which are code workflow based would need server support to get an AccessToken based on the code.
Is this right?
Thanks in advance.
Some of the concepts in Torii can be a little confusing to understand. Because it's so flexible, the answer to most questions is "it depends".
Your understanding is basically correct:
Yes, the only useful OAuth workflow which does not require a server with a shared secret is Implicit Grant.
Yes, the bearer provider does not require you to run a server. Neither does the facebook-connect provider, or any custom provider which uses the same approach.
Serverless apps using Torii cannot use an Authorization Code workflow, and would need an authentication mechanism which returns an access token. This is likely to be using the oauth2-bearer provider, but you could use facebook-connect or any other similar approach.
I am trying to build an application that will use data from multiple social services. The user will need to authorize their accounts to be accessed across these multiple services (e.g. facebook, twitter, foursquare) using oauth.
I don't really need the users to login with these accounts, really it is just allowing their data from the api to be pulled.
I know I need to use oauth, but I am having trouble finding a basic example of how to do this type of thing (a lot of examples exist for logging in with oauth).
I have been trying the python-oath2 library.
Does anyone have any recommendation for a good tutorial or example of doing this type of thing in python, and if possible django.
Thanks.
Why reinvent the wheel? There is a plethora of reusable applications that have this implemented. You can find a comparison here: http://djangopackages.com/grids/g/authentication/
Why not give rauth a try? We use this in production for this exact purpose. Although you don't need to require the user to login with your app via the provider, you're going to redirect to the provider, where they'll be asked to authenticate your application. Assuming they accept (or even if they don't), they'll be redirected back to your application, i.e. via the redirect_uri or oauth_callback, there you'll ensure they authorized your app and then proceed with whatever housekeeping you need to do, e.g. saving some info about the user in your database. Try the examples and also pay particular attention to the Facebook example. Now the Facebook example is intended for authorization with the example web app, but the same pattern can be used for what you're trying to do. (You just won't be having them login in via Facebook, for instance. However, the flow can be and probably should be identical, sans database operations and template login lingo.)