I'm writing an app development guide and I'm struggling with a few things:
First of all there are currently 2 endpoints in AAD (v1 and v2), there are also 2 pathways of registering apps in the AAD portal (app registrations and app registrations preview). I can't seem to find confirmation that usage of the app registrations preview blade enforces usage of the v2 endpoint, can anyone confirm? Our users authenticate using WS-Federation which is currently not supported by the v2 endpoint which is why I want to avoid usage of v2 for now.
I'm also looking for the best method of allowing access to the Graph API through a service account with delegated permissions (for more granular scoping).
Anyone that can clarify?
Thanks
I can't seem to find confirmation that usage of the app registrations preview blade enforces usage of the v2 endpoint, can anyone confirm?
An app registered in either registration experience can be used with both the v1 and v2 endpoints. Some features can only be configured in the preview experience, though (e.g. support for Microsoft Accounts).
Related
My company wants our IT department to review and approve every tool we connect to Marketo. This is a lengthy and costly approach which I do not seem to fully understand, why. For example, I would like to use the Marketo integration with LinkedIn, Contact Forms 7 (WordPress plugin), or Zoom. There are already existing integrations with Marketo which can easily set up via the API Code provided by Marketo. However, my company wants to review all these as all API integrations have to be reviewed by IT. Does this make sense from a security or functionality perspective? Are the existing Linkedin, Zoom, WordPress integrations proper API connections? What is the difference between an API and integration in Marketo?
Thank you for your help.
I think with the API integration, that would use your own daily API limit whereas the native (existing) connection in Marketo where you can connect to Linkedin or Zoom integration is via Marketo background API which does not count towards your limit. In terms of security review, you might want to discuss to get the details off your Account Manager perhaps.
I am facing the challenge to request the Bing Ads API to get a couple of metrics from it.
I am using Apache Airflow DAGs hosted on a remote Kubernetes cluster to do so. It is a nice way to automate and schedule tasks.
Now, the documentation is rather light on the point of gaining access to the API.
I have followed this https://learn.microsoft.com/en-us/advertising/guides/authentication-oauth-identity-platform?view=bingads-13#registerapplication
and the official SDK docs https://github.com/BingAds/BingAds-Python-SDK/.
I am failing at authenticating when querying, since I am lacking a couple of pieces of information.
When authenticating using the "refresh token" and "redirect URI", I do not have either. (Class OAuthWebAuthCodeGrant here: https://github.com/BingAds/BingAds-Python-SDK/blob/294d01eea57d80ba381a42cde8d006fc318af056/bingads/authorization.py#L566)
When using a different method (Class OAuthDesktopMobileAuthCodeGrant here: https://github.com/BingAds/BingAds-Python-SDK/blob/294d01eea57d80ba381a42cde8d006fc318af056/bingads/authorization.py#L532), I fail w/
AADSTS700016: Application with identifier '<someidentifier>' was not found in the directory '<somethingelse>'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.
Thank you very much in advance! If you need more details, let me know!
Also great documentation in general, if I can make it more "newb"-friendly, let me know!
Edit1:
Sadly, while there has been some traffic to this question, nobody seems to be able to answer.
I will specify the set up a bit further.
We use Airflow DAGs to request daily updates from the API. For this, we need to authenticate. The authentication comes from a "new device" every time, since the code runs on a k8s cluster which allocates the jobs dynamically to it's pods.
For authentication, we ventured into different solutions, but all require some form of human interaction to get the refresh token into the DAG.
Is there any solution which allows for a hands-free deamon like many-server-to-server communication?
This link sheds some light on what we are looking for: https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-app-registration#api-permissions---app-permissions-and-admin-consent
Sadly, the Bing Ads API does not show up there.
What key piece of information are we missing?
Bing Ads, like Google Ads, uses OAuth for its API.
If you reference the Getting Started page, it mentions that you need a developer token, complete with links.
You can follow these steps to get a developer token for production.
Sign in with Super Admin credentials at the Microsoft Advertising Developer Portal account tab.
Choose the user that you want associated with the developer token. Typically an application only needs one universal token regardless how many users will be supported.
Click on the Request Token button.
Regarding your specific scenario--an application running in the cloud without an interface--you should know that OAuth requires you to interact with it to set things up. So run your app locally ONCE, or at least the getting_started code from your language's walkthrough: https://learn.microsoft.com/en-us/advertising/guides/walkthrough-desktop-application-python?view=bingads-13
Running it locally will go through the authentication process with your browser and generate a refresh token (in the file refresh.txt by default). Store this file with your code. It will have to be on the server that's making the request, and since it's in Kubernetes, you'll have to keep it with your container file.
On our existing AAD, we are trying to integrate with FIDO2 authentication.
As part of this integration b/w AAD & FIDO, in azure portal under "Security
Authentication methods | Authentication method policy (Preview)" AD Admin have been provided UI options to enable FIDO Authentication either for a particular user or group which will be followed by end user side set up process using MS self service portal "https://myprofile.microsoft.com"
Are the above steps involved in AAD & FIDO integration, can be accomplished programmatically via graph api endpoints or any other rest end points?
Is AAD having its own API public endpoints apart from Graph API endpoints?If not why AAD not having its own API public endpoints?
The above steps for AAD and FIDO integration can be done via portal at this point . The underlying functions involved are not exposed through any API at this point . the feature is still in preview and is a work in progress. This may change a little more before it goes GA depending upon existing feedback by the users/customers and internal tests.
There is older API called Azure AD graph API but its not being actively developed for any new features. The Microsoft Graph API is the newer API and it is being designed as a single consolidated API (single endpoint https://graph.microsoft.com) with a robust back-end to interact with Microsoft 365 cloud Services. Earlier Micrsooft had many different APIs to manage end user experiences and Identities however as we evolved a lot of customers/partners demanded consolidation so that it was easier for them to write their customer code for management and build any software on top of Microsoft Azure AD hence one single API backend was built and released as Microsoft Graph .
As for the programmatic access to FIDO settings , I would suggest you to upvote an existing feature request related to the same on Azure feedback site. The Azure Feedback uservoice site is periodically reviewed by the product group and it helps in prioritization of requested features for development.
Trying to setup a bunch of logic apps with supporting Azure functions etc. concept is to utilize ML/Azure functions/Logic apps etc. to setup an automated mailing system.
Everything is deployed using ADO/Git with CD/CI pipelines, but we have a problem with the Office365 connector that needs authorisation after creation. For now, we have followed this article that creates a windows form for authentication.
This works fine, but we want to do this at scale and thus are looking for a silent approach, any ideas or links would be appreciated?
PS. Use does not require MFA
At the moment, the Office365 API authorisation works with the OAuth 2.0 Authorisation Code Grant Type, which means, you can only get the authorisation code by getting the user owning the mailbox (or having access to the shared mailbox) to sign in to get the code. This behaviour of the API is by design. Thus, there is no way to fully automate this.
If you don't need different accounts for different Logic Apps, you can create those API connections with PowerShell (still requiring the user to login in) for each environment and then use the already provisioned API in our CD pipeline.
I'm trying to interact with the Salesforce REST API for an organisation, and was wondering if it had any notion of Service Accounts or Application Owned Accounts. I can't find any mention of it in the documentation, but maybe they use different nomenclature.
I'd like to enable some form of domainwide delegation of authority, so users aren't faced with the pop up requesting access to their data. This is an internal app, only for this particular organisation.
No, there are not service accounts. There are 'Chatter' user licenses that are free but have reduced functionality: http://www.salesforce.com/chatter/getstarted/?d=70130000000tRG7&internal=true#admin
FAQ: http://www.salesforce.com/chatter/faq/