I'm looking to provide a service to people using GCP.
Given that I'll be accessing their GCP monitoring APIs from my server, it seems like that would be best done using a service account. That way it's not tied to an individual user, and won't stop working if that user is removed from their organization.
Creating a service account manually is not too complicated, but definitely more complicated than just presenting the user with an oauth permissions flow.
Is there any way to create a GCP service account using an oauth flow so that I don't have to force the user to create one manually with the correct permissions?
I've looked around, and can't find any documentation on this, which leads me to believe that it's not possible.
You can create service accounts programatically with the projects.serviceAccounts.create API call. This call must be made by a user authorized with iam.serviceAccounts.create permission (e.g. owner or iam.serviceAccountAdmin role). Code to do this would look like:
import googleapiclient.discovery
import httplib2
credentials = GET_YOUR_USER_CREDS()
http_auth = credentials.authorize(httplib2.Http())
iam_client = googleapiclient.discovery.build('iam', 'v1', http=http_auth())
iam_client.projects().serviceAccounts().create(name="projects/PROJECT_ID", body={"accountId":"SERVICE-ACCOUNT-ID"}).execute()
Related
I am writing an api using the msgraph api which should be able to read mail from shared mailboxes. I have setup the application in Azure and have given the following permission (my app is running as its own service and not on behalf of an user)
What I am confused about is
Why does it show Delegated, all the rest of my permissions to the application show Application.
Since this is an application how does an user share a particular mailbox with this application, what I can think of is to create a service account, then this application impersonates that service account and then uses the service account to access the shared mail, but this sounds like a really complicated process and am wondering if I'm heading down the correct path.
thanks in advance.
From the Microsoft graph permissions reference, Mail Permissions Mail.Read.Shared and Mail.Send.Shared require a signed in user which is why the permissions show up as delegated. To the best of my knowledge, there isn't currently a way to access shared mailboxes via Ms graph without a signed in user.
Please let me know if this helps, and if you have further questions.
So I applied as a Twitter Dev to make a bot that tweets stuff. About two days later, I got access. When I ran the code with the tokens it gave me, it posts from my account.
My question: Is there a way for me to make it send as another account (a bot account) without me having to apply again?
Yes, you can use the Sign-in with Twitter flow to authenticate a different user to your app, and then use the Access Token and Access Token Secret for that user to post to that account. This is the correct way to implement things - you should not be applying for multiple developer accounts.
You can also use tools like twurl or another CLI tool to
https://github.com/twitter/twurl/
https://github.com/smaeda-ks/tw-oob-oauth-cli
https://github.com/olithissen/twitter-oob
Did you get elevated access from tweeter or Essential? I have a stack error:
You currently have Essential access which includes access to Twitter API v2 endpoints only.
If you need access to this endpoint, you’ll need to apply for Elevated access via the Developer Portal.
It's hard to get Elevated now.
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.
I need to authenticate to an API using OAUTH2, however, it has to be made programmatically, no user typing stuff in a browser is permitted.
This seems like such a simple use case, but I haven't found anything online, the only thing close to it was this post, and the only answer is "yeah, you don't want to use a web browser, but what if you do?"... This doesn't help.
So, please, opening a web browser is not an option, I just want to know if Google provides any way to authenticate purely through code.
Thank you!
In order to achieve your goal, I would like to propose to use the Service account. When the Service account is used, the access token can be retrieved without using the browser.
As the points for using the Service account, please check the following points.
The Service account is not your own Google account.
For example, as one of several situations, if you want to manage a file in your Google Drive using the Service account, please share the file with the Service account. By this, the Service account can access to the file in your Google Drive.
References:
OAuth2ServiceAccount
Several cases using the Service account
Google Drive Access - Service Account or OAuth - To read/write user files
Google service account not being authorized for calendar API
Service Account for google sheets returns not found
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. :-)