Advice on multiple projects sharing authentication (DRF) - oauth

I'm looking for some advice on setting up one authentication service for multiple different django projects.
Currently, I have one project that uses AWS Cognito for auth (with django-cognito-jwt). Then I have a separate project that does the same thing using a different AWS Cognito user pool. These projects are not connected in any way. The current flow for each app looks like this:
(1) Go to one project and login via frontend
(2) Use AWS Amplify to authenticate user against cognito and return a JWT
(3) Hit my DRF API and call get_or_create_for_cognito to parse JWT
(4) If account is new, create Django User object in the database storing the ID from cognito
(4) If account already exists, lookup User record by cognito ID and return that
(5) With this returned user object, I can lookup groups and permissions associated with user to allow or disallow various endpoints.
My goal, is to have one cognito account allow a user to authenticate on both of the different projects.
I understand that I can just point both projects to the same "User" table, but a few different sites/blogs have talked about this being bad practice. Some people have mentioned introducing a 3rd django project that's sole responsibility is Authentication. However, most of the examples I have found are using django's built in authentication not cognito.
So at a high level I'm wondering if anyone has any idea for how to architect this, or any example project using cognito that might be helpful for me to read over.
Thanks for any help!!
I've also read over this similar post:
Multiple Django apps, shared authentication
but my requirements are different because I'm using JWT auth and cognito

I don't think you need much architecting. Why not just put two app clients on the same user pool? Then you simply target the same user pool from both apps, with different app ID's. Users will be shared, and each app gets its separate client config.

Related

Integrate my own IDP (Similar to okta) and CIAM into BigCommerce store

I have my own IDP and user store which is used by other apps in order to allow users to login. Right now i am trying to spin up a new storefront using BigCommerce ecommerce platform , for this app i need to use the existing IDP and user store so that users who are using the other apps can single sign-on into the new store front app as well. Can anyone please help on where to start on?
I also had a look into the big commerce Login API using which once can able to login using JWT token for the customers existing already in Bigcommerce platform, But in my case all my user data are store in my custom IAM and i need to log those users into store front seamlessly.
Thanks in advance
You need to provide BC Login API with a signed JWT. That JWT needs to contain the BigCommerce userId to enable it to login. To create the JWT you will need a client ID that can be created by creating an app in your developer account, thus creating the trust and not requiring credentials, just a userId.
This gives some help on creating the JWT and all the info required within it:
https://developer.bigcommerce.com/api-docs/storefront/customer-login-api
And this is a simple example of it working using Express middleware and Auth0:
https://github.com/bc-simonpallister/bc-auth0-oidc
For BigCommerce Single Sign On (SSO), you can definitely use the following information mentioned - https://developer.bigcommerce.com/api-docs/storefront/customer-login-api
But as I understand, you are also looking for a seamless solution for BigCommerce SSO wherein you can skip the complex coding part.
If this was interesting, here is the entire scoop for your reference -
https://www.miniorange.com/integrations/bigcommerce-sso-mfa
PS: You can also enable auto sync using above solution in case you wish to provision your users/groups in future.

"Copy this file to your authentication server" - Firebase Custom auth

My goal is to prevent users of multiple login in. I do not want this to be client-side, with like the onDisconnect and onConnect values, but with a server check. I came across this answer:
How to prevent simultaneous logins of the same user with Firebase?
Which tells me to create a custom auth system. When I am following the docs (https://firebase.google.com/docs/auth/ios/custom-auth) I need to "Copy this file to your authentication server" (3c). How would I do this? I am just using Firebase and my little iOS app. I would like to manage everything on these 2 things, no server in between, is this possible? Or can this file only be uploaded through another server?
If above things are not possible, how can I server check if the user really signed in? I am using Cloud Functions, but I did not came across a trigger for a user signing in. Please no answers with onDisconnect/onConnect, I want it server side. A user may NOT login if he is already logged in. Thanks :)
Implementing custom authentication requires that you have a secure place to mint the custom token that identifies each of your users. You cannot do this securely with only client-side code, because that would mean everyone could claim to be whoever they want.
While you can use Cloud Functions for Firebase to implement a secure back-end without spinning up your own server, I highly recommend against doing that just for the purpose of preventing a user to sign in from multiple locations.
It's important when talking about security to split these two steps:
Authentication - a user proving to be who they are
Authorization - the authenticated user being able to use your app
There very seldom is a reason to keep a user from proving who they are. Your concern seems to fall onto keeping them from using the app from multiple locations. To do that, it's probably easier to track for each user where they are using the app from already using Firebase Database's presence system.
Also see:
How to handle multiple connections of the same user on Firebase?
Android - How to detect same user from multiple devices?
How to prevent same user logging in from different devices ? My app is paid , so I dont want credentials to be shared

Microsoft Graph API auhetication for service apps

We are developing a web application using Microsoft Graph, where the signed in user can, Export all the calendar events to a third party calendar Application. After this initial export, we need to keep the exported data in sync with calendar changes via service app (a scheduled task running on server). This need to be a multi tenant application, as people from different organizations should be able to use this service.
Right now we did the authentication using OAuth 2.0 and OpenID Connect as described in this sample. Later we understood that the access token we get using this method cannot be used in the service app without user interaction. Considering our scenario what is the best way to achieve this?
I have read about App-only authorization method to do this. If we use this authentication method, the app need to be consented by a tenant administrator and the these applications are quite powerful in terms of what data they can access in the Office 365 organization. Considering we are developing a product used by different organizations, will it be feasible to use this method?
To use the client credentials OAuth2.0 flow (aka "App-only" or service account access depending on who's documentation you're reading) the admin for each tenancy will need to specify which scopes your daemon process can have for users in their tenancy. The end users can't give these scoping rights to your code themselves (as far as I know at least).
One thing to watch out for is that currently Graph API doesn't allow you to mess about with calendars that are attached to Office 365 Groups if you're using the client credentials flow. This is a pain for us, so we've raised it as an issue that needs fixing in the Office 365 feedback system. if that's an issue for you or anyone else, please throw a few votes at it so that it gets more attention at Microsoft. :-)

Using DynamoDB without Cognito API

I am using DynamoDB or any AWS stuff for the first time and thus have a very little idea how they work. I have seen the documentation where it's mentioned that to use DynamoDB, using IAM and Cognito sync is better way.
I have a very simple requirement. I have an iOS app in which a user can register and login. The functionality is provided by a third party SDK, but I want to store the user information in the DynamoDB table named as Users.
I am not sure if I need Cognito Sync or IAM for this.
So My question is, is it possible to use DynamoDb in iOS without using these two extra features? If yes, then is it possible to do it with the AWS mobile SDK or do I need some other ways such as using RESTful APIs for that?
When you use Amazon Cognito, the service takes care of all the steps necessary to create a unique identifier for your app’s users and retrieve temporary, limited privilege AWS credentials. This means that you can follow security best practices, and use these temporary, limited privilege credentials instead of having to hardcode credentials into your app.
You can still use AccessKey and SecretKey with AWSStaticCredentialsProvider in the AWS Mobile SDK for iOS, but we discourage its use in production apps for security concerns.

How would I tie a user auth'ed by 3rd party provider via ACAccountStore to a backend user obj in the cloud?

In general, what's the best practice to authenticate a user via 3rd party (say Twitter) using iOS's ACAccountStore and then tie it to an existing user in my own service assuming that they were logged in already? Can I access and store the account credentials remotely over ssl, or is there a better way?
And if they had to re-login via Twitter, I could just search for the user with that twitter handle to know what backend user is tied to this account, yes?
And lastly if I wanted to be able to login via a browser later on, I would get new oauth credentials for the webapp as well, but could search for a user with the same Twitter account info and store these credentials as well, and know that they all refer to the same person, correct?
What you're asking involves many levels of a system "stack" that are custom to a particular environment. What is "correct" vs "incorrect" is dependent upon the environment you've set up and are connecting to from your iOS app.
So from what it sounds like you're leveraging iOS's Twitter functionality to create a Single Sign On (SSO) experience. There are several guides on Twitter's site for doing what you want to accomplish:
Integrating with Twitter on iOS: Single Sign On
Using Reverse Auth to Get OAuth Tokens on iOS - you can then store these server-side
Migrating tokens to system accounts - how you get OAuth tokens from your webapp to iOS.

Resources