I am working on integrating Cognito with the website my team is building for user authentication. I am having troubles with regard to number of app client that I should setup. In the AWS's official documentation, it says something like this:
You can create multiple apps for a user pool. Generally an app corresponds to the platform of an app. For example, you might create an app for a server-side application and a different Android app. Each app has its own app client ID.
So normally, lets say for a full stack application, do we need to set up two app clients, one for frontend and one for backend? or it is fine just creating one app client?
You do not need to create 2 app client values to require a user to authenticate to access your web site using a login such as this one:
You only need one App client id value to secure a web app (the note above is describing a web app and a separate mobile app).
To see an example of securing a web site (this example demonstrates how to secure a Spring boot Web app using the OAuth2 identity provider), see this:
Using Amazon Cognito to require a user to log into a web application
Related
So we've completed the implementation of the google calendar integration in our pre-production application.
Now, we need to submit the Oauth app for verification and I had a few questions:
Can we create the demo app in our pre-production application or does it need to be created in the production application? [the issue with recording video in production app is that we can't deploy the feature to production app until the Oauth app is verified by Google as we don't want users to see an unusable feature. ]
If we have both mobile app and web app where we've integrated the Oauth app, do we need to create demo videos in both apps or can we just create video using either mobile or web app?
We're using the same Oauth app(that we're going to submit for verification) for our pre-production environments as well right now. Is this a valid practice?
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
Essentially, I'm wanting to create an Oauth Client as an App so I can get data from Dynamics for multiple customers. Does anyone know if this is possible to do in AppSource or do you know of another way?
I have a service that will be served in a cloud different than Azure so there really isn't anything for me to submit as an App and I really don't want every customer to have to setup their own App that gives my service the privileges/access it needs, but it's looking like I may have to.
It sounds like you'll want to register an app with Azure AD (the OAuth2.0 service/identity provider for work and school accounts), and create a multi-tenant app. Then you can configure this app in the Azure Portal to get permissions to the APIs the app wants tokens to call (in your case Dynamics or the Microsoft Graph).
Once this app is written, you can code up your app using one of the Azure AD Auth Libraries. Here's some sample code for a .NET web API. You can find more code samples on Github and search active directory. Moreover, the Azure Active Directory Developer Landing Page is a great place to look for more resources on doing all of this.
I am creating a service that will include a website, a mobile app, and a web service.
Both the website and mobile app will talk to the web service to interact with the database and any other backend items.
I would like users to be able to log in with other services (such as google, facebook, twitter, etc.)
I have two questions in implementing this:
1.) Should I use OpenID or OAuth? I'm not sure which is better for the situation. I have no need to actually access features from a users account, I just want them to be able to log in with accounts they already have,
2.) Where should I implement the authentication? Do I have to implement it both on the website and on the mobile app, or could I have both talk to the web service and do the authentication there?
Thanks
If you are just doing authentication and not syncing any account details, I think OpenID is the way to go. From a security standpoint, I would say to implement your authentication on the website and on the app and not in the webservice. You want to handle credentials the least amount possible and especially avoid sending the credentials via webservice if not using SSL.
I want to upload a file to a website via a desktop app and then take the user to the website. The website has a web service, but requires authentication as does the web site. Is there a way to do this without forcing the user to authenticate twice (once in the desktop app and once in the web browser)?
Unfortunately, you can't prefill an input of type file for security reasons, which makes sense since the user won't want you uploading arbitrary files from his/her computer. But if they have a desktop app, is there some way around this?
Or maybe make the user log into the web app first and then the authentication cookie can be reused?
Any other ideas?
Thanks,
Ben
I would use the dekstop app as a client to the website app via an api.
So, login via the desktop app. The api returns a authentication token (as Carlos suggested) which might be a md5 hash stored in your database for a certain period of time, possibly matched to the clients ip address.
The desktop app can then make calls on the api (like uploading a file) as a authenticated user (by using the auth token).
When loading the website, perhaps the url is http://website/login/{auth_token} where the auth token is added to the url. The api can check to see if its a valid auth token and consider the user logged in.
You could generate an authentication token that could later be used on the website.
It all depends on the type of authentication of the service and the site. Is it integrated Kerberos, WS-Auth, is it Basic/Digest HTTP, is it forms/cookie ?
This answer will most likely not work in the very general users-on-the-wide-open-web scenario, but in intranet contexts, using Windows Authentication (on an ASP .Net solution), would provide this.