Is it possible to use ember-simple-auth with multiple auth providers at the same time? For example, in my website I want to call few google analytic APIs using google's JWT auth token and other APIs using custom oauth2 token.
You can have few authenticators, but use only one authenticator at the time. It's mentioned in docs. So the answer is no. It's because you have only one session service, which holds authentication status. And I don't see a way of solving this without heavily modifying ember-simple-auth.
Related
I want to get my head down into a small community website using Django Rest Framework as a backend and Next.JS as a frontend. I am struggling with the authentication module.
What is best practice? I thought about using Firebase as an auth provider but the implementation is quite hard - or at least I could not find good documentation.
I am now thinking of using the Djoser library to have django handle all authentication and user management.
My question is: What would you recommend to use? The official DRF website has a ton of third-party packages on this topic but I just can decide which one to use (https://www.django-rest-framework.org/api-guide/authentication/#third-party-packages)
You can use Next Auth to handle JWT authentication.
If you are using Token authentication (rest_framework.authtoken), you can store the token in localStorage and inject the token using axios.interceptors.request.use for axios, or create a custom fetch method that injects said token in your fetch headers.
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.
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.
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.