I have already created a web platform to allow users within my organization with an #xxxx.com account to authorize their Google Accounts to send/receive email messages within the platform. The new messages reception is currently done manually by a "New Email" button, but I require an automated process running in the background to pull the email messages frequently.
I tried to do it with refresh_tokens for offline access and a periodic cron job but because there are a lot of users' accounts, that process would take too long to connect to each account, pull messages, and such. This may not work properly.
Is there any other way (using an API) to pull the users account email messages directly (something like an Audit or SuperAdmin account)?
Is there any other way (using an API) to pull the users account email
messages directly (something like an Audit or SuperAdmin account)?
Yes, it is called G Suite Domain-Wide Delegation of Authority.
In summary, you create a service account and use that service account to access email for all users in your domain. You can also use this method to send email on behalf of users.
I have done this many times. An important tip is to follow the instructions "exactly" otherwise you will get permission errors.
Perform G Suite Domain-Wide Delegation of Authority
Related
On Google Workspace, I have created an email that I only need to check programmatically.
For that, I'm going to use Push Notifications but I'm not really sure about the authentication part.
Apparently, the only way for a service account to access (impersonate) a user's mailbox would be via domain-wide delegation, something Google doesn't recommend if there's another way.
Avoid using domain-wide delegation if you can accomplish your task directly with a service account or by using the OAuth consent flow.
My question: what other ways are there?
Is it technically possible for a service account to impersonate a single user?
Regarding the OAuth consent flow, how could I make it work (how would the user consent in this case) considering this would be server to server communication?
I am currently using AWS Cognito and it's hosted UI to manage user login. All my users sit in a single pool, which has a number of different app clients registered. Our users are grouped into different organisations and for the most part a single user (or email address) is only associated with a single organisation, so this setup works very well. A small subset of users are associated to multiple organisations. Associated to a particular organisation is managed by a backend service rather than using Cognito attributes and/or groups.
We are already using the pre token generation Lambda trigger to inject claims into our tokens to denote which organisation a user belongs to which is then used downstream in our backend services to control which database is hit when a user makes an API request (we use single tenant databases).
I need to design a mechanism that will allow the users who belong to multiple organisations to select which organisation they want to login as (ie select which tenant they want to use for that session) at auth time. I know this will be impossible to do with the Hosted Cognito UI but I'm wondering if this is something that can be done with AWS Amplify along with a custom login app and using custom auth challenges. The flow would be something like this:
Username/password provided
Custom auth challenge lambda fires which detects whether the user has a 1-1 relationship to a single organisation (in which case we can log them straight in) or a 1-many relationship to multiple orgs.
In the latter case above, the auth challenge returns a collection of organisations that a user is allowed to log in to back to the app which displays them in a picker control (drop down or similar)
User selects their tenant and this information is sent to the auth challenge response and the login continues.
A key step after this would be ensuring that the custom challenge responses make it through to the pre token generation Lambda function so it knows which organisation the user is logging into.
I'm a backend developer and have had no exposure to Amplify at all, I just need to know if this is theoretically possible before I invest too much time into it.
Can anybody with Amplify experience confirm if what I describe would be possible using Amplify and a custom auth React app?
Thanks
I am developing an app with cognito for authentication and user management in a multi tenant application.
And the app provide a different app per client. Meaning one client will have its own cognito user pool and they get their own domain to login.
So the problem i anticipate in the future is we could reach more than a 1000 clients and the AWS cognitio limit of 1000 will be reached.
In this case the only way i can think of handling this is to create a new AWS account and getting more user pools from that account.
But i dont want to have to manage multiple AWS accounts in the future. I dont think we should use the same user pool for maintaining multiple clients because since each client gets their own app.
Not sure what is the best way to handle this.
Looks like the only way to do it would be to use a shared user pool among organizations.
And for each organization i need to create a different app client in cognito and make it work in that way.
And for the problem of users in one organization being able login in into other organization's app, due to the shared pool. I will have to create a validation layer before login in the application to to make sure that the username/email has the access to that organization or not.
I'm a beginner when it comes to Google Cloud. I have only worked with AWS before, but for this purpose I want to give Google Cloud a try.
I want to create an application where I don't have human users, but instead there are multiple instances of the same client application trying to access the pub/sub service. I would like each one of these users to come to register with my cloud function, which in return will:
create a pub/sub topic that only this client can listen to
return an identifier/key/something that can be used to authenticate the client the next time
How should I handle the authentication in this case? Should I create service credentials for each one of the clients? Or is there a way to provide a custom Identity Provider?
The first question is answered in this answer.
For the second one, the best way is for the user to be identified with Google oauth (a.k.a. a Google account).
When you create the pub/sub topic for this user, you should have already identified them, so you can set the proper permissions on the thread. Then, the user can simply call the pub/sub endpoint identified.
GCF, GAE apps, apps running on GKE, ... all of those have service accounts associated with them, so there should not be a problem to properly identify each client app running there.
If those users don't have an account (e.g. the client app is running outside of GCP), you can ask your human users (the ones running the client apps) to either:
Authenticate with their user account on your client app
Create a service account in GCP and make the client app use it
If those are not options, you can create a service account for each of your users, and provide the proper service account key file to each client.
So since parse is shutting down we are moving our website / mobile app that we've been developing to AWS. We are primarily going to use the following services:
SNS, SES, Dynamo, S3, Lambda.
Now I am still a bit confused on:
what cognito is used for? Do we really need cognito to authenticate users and use DynamoDB, S3, SNS ? Or can we just use specific APIs for each of these services and connect directly (using Js SDK)?
If we do have to use cognito how do we save local data i.e logged in user/ identity? is that what cognito sync is for or do we have to use cookies ?
In summary why do I need cognito when I can directly connect to DynamoDB using the JavaScript SDK?!
Thank you in Advance.
Amazon Cognito can be decomposed in two sub-services: Amazon Cognito Identity and Amazon Cognito Sync.
Think of the former as an authentication service and a credentials provider. The latter is just a service to store user data and keep it synchronized between multiple devices.
What is the purpose of Amazon Cognito Identity?
Suppose that you have a table in DynamoDB. Let's say that you have a web application that will store an item on that table.
You can create an user in IAM, embed the credential information on the web application, and then put the item on the table using the AWS SDK.
There are three things going on here:
The credentials are embedded in the application
The credentials do not expire.
Every user in your application has the same access rights on your table
This may be fine for some applications, but Amazon Cognito Identity offers a solution to these common problems.
Let me explain Cognito Identity's workflow:
An user registers an account on your application, sending all the information (username, password, other data...) to your server.
The server stores the user in some back-end database (it could be a DynamoDB table) and creates a new identity on the Cognito service. This identity is then mapped to this user.
The user can now login into your application. The user logins and sends username and password to your server. (This process could be done automatically after account registration)
The server checks the username and password against your back-end database. If everything is right, then the server makes a request to Amazon Cognito for a temporary access token.
The web application receives the token and makes a request to Amazon Cognito (using that access token) to get the user credentials. These credentials are basically a temporary IAM user that was created specifically for this user. It will have an expiration (usually an hour).
The web application uses these credentials to make operations on AWS, such as putting an item on a DynamoDB table, or calling a Lambda.
When the credentials expire, the user must re-login into the application. This might be done automatically or not, depending on your application's requirements.
On the Amazon Cognito dashboard, you can configure roles and policies for your "identities" (an user in Cognito). This way you can specify which services it can access. It even allows you to create access roles for your users (Admin users may be able to access some services that normal users should not).
I should also note that Amazon Cognito can be easily adapted to support Facebook / Google+ / Amazon accounts, which will be mapped to the same identity, so the user can login via multiple sources.
What is the purpose of Amazon Cognito Sync?
Consider it like a DynamoDB table where you store information for a specific user. These information is shared between multiple devices and is always synchronized. This means that when a web application updates an user value, then the mobile application will automatically reflect this change.
There is a limit on how much user data you can store (I don't remember now), so it's not something you would use to persist information (such as an user password), but rather a mean to share information.