Automate OneDrive Authentication with AAD MFA with python - python

I'm finding a way to automate the authentication from AAD with python.
In the past i used username and password for login to OneDrive and it worked properly. Here is the code:
pca = msal.PublicClientApplication(CLIENT_ID, authority=AUTHORITY_URL)
token = pca.acquire_token_by_username_password(USERNAME, PASSWORD, SCOPES)
Now, that i have two factor authentication i cannot use the same code to access OneDrive account.
I've searched the internet but all the solutions that i found requires to open the browser, and i can't do this because python script is a chronjob and runs in the late night. I need a solution that works in "background" without any action required.
Possibly it's better if there is a solution with MSAL library due to some permissions that i should request if i would change the library.
Thanks for the help!

You might consider using the Client-Credentials Grant flow or OAuth2. You would have to modify your cronjob to move away from fetching a token on behalf of the user and update it to acquire a token as the application using the application's identity (the app registration done in AAD). Upgrading to client-credentials flow, which is actually designed for scenarios similar to yours, will help you in situations where you cannot afford user interaction and you want the service to work in the backend.
For more information on Client-Credentials flow, check here.
Also, you can refer to the following python app that implements client-credentials flow:
Call Microsoft Graph API using App Client Secret
Call Microsoft Graph API using App Client Certificate:

Related

OAuth2 Token on Microsoft Graph API

I'm looking for the most simple way to gain a JWT token to use when calling Graph API endpoints. There is endless documentation about OAuth2 and so many ways to do that, but I got lost in the process.
My scenario is a backend program listening to an Outlook mailbox.
I read about registering my service in Azure AD etc., but I'm looking for something quicker that bypasses everything. I know such solution exists because in the Graph Explorer it is done fairly easily. I only need the JWT token to make the calls work, nothing more.
I tried calling /common/oauth2/v2.0/token, but it needs a client_secret which I don't have because I haven't registered my service in Azure. I've tried endlessly to mimic the process that is done in Graph Explorer, but with no luck.
I’m sorry to announce that, but Graph Explorer is an Azure AD registered app by default and you will have no choice but to create an app, this is how Graph API works, and for that, you can follow this link for a non authenticated use https://learn.microsoft.com/en-us/graph/auth-v2-service or this link for calling Graph on behalf of a user https://learn.microsoft.com/en-us/graph/auth-v2-user

API call switching to Oauth 2.0 with openid

I used to query my financial data through Power Query in Power BI. Recently I've switched to doing it through a python script running on Google Cloud functions, triggered by Cloud Scheduler. (is this the best way?) It saves a csv file to GCStorage.
The party that provides the data I'm after is switching to oAuth 2.0 using either implicit or authorization code flow. I believe this means that somewhere in this flow a browser is opened where username and password must be entered. Also I need to give a redirect uri to this party, I'm not sure how to implement this in my current setup.
Anyone have an idea? More info about the API can be found here. https://accounting.twinfield.com/webservices/documentation/#/ApiReference/Authentication/OpenIdConnect
Usually the Authorization Code flow would be the way to go in your kind of application.
You will send a authentication request to their API(redirecting the user). They will authenticate the User and redirect the user back to your application, using the redirect URI you provided.
You can get an access token or ID token from their token endpoint using the code, your client id and your client secret.

Authenticating google cloud behind corporate firewall

I am trying to use Google cloud's natural language API at work, and I believe my corporate firewall is blocking communication between python and google cloud.
After entering the following in the terminal:
gcloud auth application-default login
My browser opens up to log into my google account successfully. After I log in, however, I get
ERROR: There was a problem with web authentication. Try running a
gain with --no-launch-browser.
ERROR: (gcloud.auth.application-default.login) Could not reach th
e login server. A potential cause of this could be because you ar
e behind a proxy. Please set the environment variables HTTPS_PROX
Y and HTTP_PROXY to the address of the proxy in the format "proto
col://address:port" (without quotes) and try again.
Example: HTTPS_PROXY=https://192.168.0.1:8080
I believe I need to contact my IT department to add an exception to our firewall. Does anyone know what the address / port for google cloud's natural language processing API is?
I can't directly answer your question but I can provide some general guidance that might workaround your issue.
The command
gcloud auth application-default login
Is a convenience helper for running sample code locally but it's really not the best auth strategy for a variety of reasons. It uses a special client ID that won't always have all your quota.
The way I would recommend using the API is Service Accounts. You can create a Service Account in the Cloud Console under API credentials, and then download a JSON key. Then you set the environment variable GOOGLE_APPLICATION_CREDENTIALS to point to your file, and it will automatically work assuming you are using Application Default Credentials (which most samples and client libraries use).
On App Engine, and Compute Engine (assuming you created the VM with the correct scopes) Service Accounts exist by default so you don't even need to download the JSON and set the environment variable.
The other way you can use the API is just creating an API Key, then hit the HTTP endpoints with ?key=api-key at the end of the URL. API Keys are also less than ideal (no idea who client is, no scopes), but are a simple option.
In your case, I'd recommend using JSON service account keys and the environment variable, but it's worth reading the official authentication guide.

How to setup authentication for Salesforce service

I'm building a python service that syncs data with Salesforce in both directions. To use the service, each user will have to authorise his own Salesforce account.
I've looked at Heroku Connect, but it doesn't seem to support a scenario where many different accounts can automatically be connected. Then looking at the API examples I noticed that almost always there is a user account as well as a password used in the request.
Being used to Gmail's APIs, I'm thinking if it is really necessary to ask for and save the user's password, or if there is another way to authenticate the requests. Requests will typically be initiated by the backend at random moments.
There's so much available from Salesforce that I am not sure where to start. Any suggestions would be appreciated.
You need to use the OAuth Web Flow to enable your app to make requests on behalf of a user. There is a Python utility to help with that: https://github.com/heroku/salesforce-oauth-request

Is it possible to use the Spotify Web API to write a desktop application without a callback URI?

I would like to write a simple desktop application for personal use that uses the Spotify Web API to build playlists.
As far as I can tell, however, there's no way to use the API without providing a callback URI, which I don't have, seeing as I don't have a domain or server of any kind (other than my personal computer).
Is there a way to use the API without a URI?
If not, what is the best way to set up a callback URI? I don't have much of any experience working with web applications or client / server stuff, and the APIs I've used in the past haven't required any kind of callback.
Some background first, this answer became a bit longer than what I anticipated.
You need an access token. There are three ways to retrieve an access token; Authentication Code flow, Client Credentials flow, and Implicit Grant flow. These are all part of the oAuth 2.0 specification, each with its own purpose.
Since you're going to modify a user's account, you need that user's permission. Now, if you didn't do any actions that required user permissions, you could've used the Client Credentials flow. That's probably the easiest flow to learn since it just requires a request from your server to Spotify's server, and the response contains an access token. No callback/redirect URI is necessary.
As I'm sure you've read, the Authentication Code flow and Implicit Grant flow both require a callback URI. This is because a flow that includes a user, and the callback URI is where Spotify redirects the user after they have entered their password on Spotify's site.
The Authentication Code flow and Implicit Grant flow has benefits and drawbacks. Access tokens retrieved through the Authentication Code flow can be refreshed, but both return tokens that are valid for one hour. This means that a user that's authenticating using the Implicit Grant flow must reauthenticate after an hour. However, the Authentication Code flow does require some backend work, since it needs to make a request to exchange a code given from Spotify's server for an access token. The Implicit Grant flow is more straight forward - you get the access token and off you go.
The callback URI can be a localhost address, so if your desktop application would spin up a web server locally you could handle the callback on the same machine that the application is running on. (It's probably a good idea to not run the web server on port 80 since that might be used by something else.)
There's skeleton code for each of this authentication flows available on Github, see web-api-auth-examples. Read more about the flows in our Authorization Guide. If you choose to run a web server on the user's machine, I recommend that you use the Implicit Grant flow since that doesn't include any server-to-server requests, so you won't have to expose your client_secret exposed in the code. (As opposed to the Authorization Code flow.)
Also, since you're coding in Python, I recommend that you have a look at spotipy, a wrapper around the Web API packed with convenient methods that'll save you some time. If you do go ahead with the Implicit Grant flow, you should have a look at spotify-web-api-js, which has a similar purpose. Note that these wrappers are not at all required to work with the Web API but they'll make your life easier.

Categories