I'm using Microsoft Graph API to access data from my Azure AD, including adding and updating users.
Is there any way I can limit access to the Graph API based on the client's IP? So that requests originating from a specific IP or an IP range will be served, and the rest will be blocked?
As far as I understand, Graph API deployment https://graph.microsoft.com is a public API that is protected by Azure AD. As long as you have a valid access token you are able to call the API and do what the access token says you are allowed to do regardless of where you are. This means access restriction can only be done at Azure AD level during authorization.
If you apps are user interactive then you can try using Azure AD Conditional Access Location Condition.
For daemon apps that run on server-side, this case may not apply because they run behind your trusted networks in most cases.
Related
we're providing an OAuth app accessing the Microsoft 365 services based on the Graph API.
Some customers want to allow access only within designated IP ranges.
When I tried to apply conditional access for IP control, however, I faced the following problem:
If the scopes don't include openid, conditional access doesn't apply at all.
Once an access token has been issued, the conditional access settings can no longer restrict the use of the token (for example, the token can be even outside the designated IP range).
Is there any solution for these?
IP address is not a factor in the token. Consider that your app requires both an access token as well as an incoming request that us from a specific IP range. You can reject the request for either reason.
I have to read User emails (particular subfolder), One Drive, Team Channels and Sharepoint after some regular intervals at the background using Microsoft Graph API but not without having the user consent which should be taken only once when they logged in to the web based application first time and not afterwards. I am not sure where to start from and how this can be achieved? Should the token be stored forever in some database securely OR Is it the AAD?
Would really appreciate any pointers/APIs/Libraries/concepts or links which can help in moving towards this direction.
If you want to get the token without user, client credentials flow can be used. The flow permits a web service (confidential client) to use its own credentials, instead of impersonating a user, to authenticate when calling another web service.
In the client credentials flow, permissions are granted directly to the application itself by an administrator. So it is necessary to use the application permissions. You could call Microsoft Graph API with the access token.
For example, call this API to get message:
You need to add one of the application permissions to API permission(navigate to Azure Active Directory-> your application), and click grant for your tenant.
I'm working on OData/webAPI service implementation. PowerBI desktop app will be used to retrieve info from the service using odata feed datasource.
Service in protected by Azure B2C auth. Accessing odata endpoints using browser works fine - after signing in access is granted. But when I'm trying to connect to the feed using powerbi desktop by performing signin attempt, it reports that token source is not trusted.
picture related: sign in error
Also, in case of single-tenant Azure AD auth (not B2C) usage, authentication in PowerBI worked though.
So, is there a possibility to make PowerBI work with Azure AD B2C (to make it trust the token source)?
No, Azure AD B2C does not issue tokens which Microsoft first party services recognize. AAD B2C is used to protect you own services which you supply to your own customers.
If you would like your customers to have self service sign up, and access Power Bi resource, then have your front end web app talk to a backend API. Protect the front end and backend with AAD B2C. That backend API should use client_credentials to authenticate via AAD endpoints to access Power Bi data on behalf of the user.
I have a WebAPI (A) hosted on Azure protected by Azure B2C (B) which is being called by a mobile app (C) - this is all working correctly.
I now want to allow third parties to access my API via API Management on the same platform but I am getting extremely confused with authentication and "audiences".
The API Management developer portal has been configured as per the Azure documentation so that when the developer makes test calls on the portal it prompts for authentication using the B2C domain (B). To do this it uses an application registered against the B2C domain.
However when I want to implement the API from a third party system (D) I need to allow the system to impersonate a user when calling my API (A) so that operations happen in the context of an authenticated user on the domain (B).
I know B2C does not yet support "On Behalf Of" as a valid flow so I use hellojs to obtain an access token on the client which I pass to the third party system API via a custom head which it then appends as an Authorization header to it's call to the API.
The API Management product expects a "subscription key" to identify the products the third party implementation can use.
Does this mean with regards to the authentication part that every third party system using my API would use the same oAuth "audience" id and therefore the same Active Directory app?
It makes more sense to me that each third party implementation would have a different app on Azure Ad but that would mean my Web API would need to recognise a huge number of audience ids and redirect uris?
Finally, how do i "hide" the Web API endpoints from public use - surely use of the audience id would allow people to circumvent the API Management product?
Apologies if I have mixed any terminology up.
1) Does this mean with regards to the authentication part that every
third party system using my API would use the same oAuth "audience" id
and therefore the same Active Directory app?
They will use the same resource/scope id (i.e. audience) e.g. https://yourwebapiAppIDURI/Read but they would all have their own application IDs.
2) It makes more sense to me that each third party implementation
would have a different app on Azure Ad but that would mean my Web API
would need to recognise a huge number of audience ids and redirect
uris?
Yes they should register their applications as clients to your B2C Auth server.
The 3rd party apps should be setup in the AAD portal to have delegated access to your web API (. "Access yourwebAPIname"). If your web API exposes any scopes access to those can be delegated too.
Now when they start the token request by redirecting the user to your Auth Server, they should provide their client id and a resource/scope value of your web APIs App ID URL e.g. https://yourwebapiAppIDURI/Read.
That should result in a token with:
aud value of the Application ID associated with https://yourwebapiAppIDURI/
scp value of Read
OK, so B2C doesnt use consent:
Azure AD B2C does not ask your client application users for their consent. Instead, all consent is provided by the admin, based on the permissions configured between the applications described above. If a permission grant for an application is revoked, all users who were previously able to acquire that permission will no longer be able to do so.
I configured an application on AzureAd to be multi-tenant, I chose to require all the permissions for Windows Azure Active Directory and Office 365 Exchange Online.
I can get a user to grant permissions, get access tokens, refresh them, OAuth works for me. I always used the "common" keyword instead of the tenant ID, because my app is multi-tenant.
Now, I would like to have (CRUD) access to a user's Mail, Contacts and Calendar with this token. Here is my problem: I am completely lost in all the possible API endpoints. Should I use: graph.windows.net, outlook.office365.com, graph.microsoft.com? This page seems to suggest that graph.microsoft.com is the Swiss army knife that would serve my purpose, but somehow I cannot find a doc that allows me to find the info I'm looking for. Plus, it seems under development and maybe too incomplete for what I want.
If I make queries against outlook.office365.com, I've got a 401 error.
If I put my access token in this token analyzer, it seems healthy although the scope field only shows the permissions I set in the AzureAd portal for Windows Azure Active Directory, not Office 365 Exchange Online.
I am kind of lost, any help would be welcome...
You have a choice:
Call the separate service apis - Your problem is that you acquired a token to call AAD, and then tried to use that to call Outlook - you need to make a separate call to acquire a token for outlook.office365.com through ADAL or through the token endpoint directly. The token acquired for AAD Graph can ONLY be used against AAD Graph. Similarly the token acquired for Outlook can ONLY be used against Outlook APIs.
Just to clarify - Azure AD OAuth can protect/secure multiple web APIs, including O365 APIs, Azure AD Graph, Azure Resource Management APIs, your own APIs and the new O365 unified API. In the first access token request, you specify the first resource you want/need to call. It doesn't have to be AAD Graph - i.e. it's not the default AFAIK. Based on what is consented to, you have the ability to request additional access tokens using the (multi-resource) refresh token. Vittorio's blog post which you link to in your comments does a great job explaining this.
Call the O365 unified API (which is in preview) and IS documented. See below. The beauty of the unified API is that you only need to acquire a token to call graph.microsoft.com and ALL the entities on that endpoint are available to you AND more. It removes the siloed nature of #1, and the requirement to get and manage multiple access tokens to call these different API endpoints. However #1 is currently GA, and the unified API is preview only at this time.
For more on #2 please see https://msdn.microsoft.com/en-us/office/office365/howto/office-365-unified-api-overview and search for "unified" in the list of samples here: https://msdn.microsoft.com/en-us/office/office365/howto/starter-projects-and-code-samples
We are working on improving the unified API documentation. If you are making pure REST calls, then I recommend starting out with the API explorer (and try things like https://graph.microsoft.com/beta/me/events and https://graph.microsoft.com/beta/me/messages to get your calendar events and mail messages), OR the API sandbox (which can show you JS code snippets, and allow you to test your own easily enough). As you can see on the REST examples, to access mail and calendar features in the unified APIs, you should be able to swap the service roots from Outlook to the unified API ie - https://outlook.office365.com/v1.0 -> https://graph.microsoft.com/beta. On the JS sample - we will be adding more capabilities here and additional samples.
NOTE: Personal contacts available in outlook.office365.com are not available in the unified API yet.
Hope this helps