I am creating Outlook subscriptions as outlined here, and setting the NotificationURL to an endpoint on AWS API Gateway. This works as expected.
However, the endpoint is now being locked down, and will require an authorization token and API key to access.
How can I set the headers on the push notifications being sent from Office 365?
I do not think you can authenticate the request sent from Office 365 REST API services by setting a bearer or something like that.
The NotificationURL you give to Office 365 REST services must be accessible publicly. But the rest of your API can be accessible only through authentication. Of course you must implement/check the ValidationToken or SubscriptionId to avoid being hacked by malicious REST calls faking Outlook subscriptions.
Related
My company distributes an application with a background service component that sends and receives mail from a single email account using SMTP/POP3.
The app uses basic authentication, but we need to implement OAuth 2.0 now due to Microsoft's planned rollback of basic auth for POP3 (and likely SMTP in the future). We have been investigating the account setup and API permissions necessary to achieve this in Azure AD.
Our current understanding is that it is possible to implement the 2-legged client credentials flow by getting an access token and then sending requests to the Graph API (eg. https://graph.microsoft.com/Mail.ReadWrite). However, our application is built to send and receive with the legacy SMTP/POP3 protocols and changing the mail features to send HTTP requests to the Microsoft API endpoints requires a partial redesign.
It appears that only 3-legged flows are supported for the legacy SMTP and POP protocols. These permissions are only available as "delegated permissions" on the Graph API. There are no equivalent "application permissions" that would allow us to use these protocols from our background service without a user present to do the initial authentication.
Integrating a browser redirect into the app for the initial authentication also requires a significant update to the application. The app is 14 years old and the original programmer is no longer at the company. Due to that fact as well as limited resources, we're hoping for a solution that doesn't involve implementing browser integration or major changes to the sending and receiving functions.
Is it possible to implement a 2-legged OAuth flow to authenticate an account for sending and receiving over SMTP/POP3?
Might any of our assumptions be incorrect?
No. It's impossible.
OAuth access to IMAP, POP, SMTP AUTH protocols via OAuth2 client credentials grant flow is not supported.
Currently the supported flows are:
OAuth2 authorization code flow
OAuth2 Device authorization grant flow
See details here.
If you have this requirement, you can post your idea on Microsoft Graph user voice.
So we built our service to give our users API Keys to access API Gateway and our service. Gateway acts as an endpoint for our Lambda functions.
The problem is, we got an email from Amazon saying that we hit our API Key limit of 500 keys. They said that we shouldn't be giving users API Keys because keys are meant for integrating with other services, not users. They said we should be using Cognito User Pools and our limit can't be increased.
The problem is, our users build HTTP requests in a tool called ManyChat - a tool for building chat bots.
Our users build dynamic requests and then save their chatbot to use that dynamic request. Our users can't go back and refresh those credentials as is necessary with Cognito tokens. The authentication method will have to use a static API Key I believe.
Is there a way to manage our users' usage while keeping the authentication credentials static?
1) Update 401 Unauthorized response template as per your need so that it contains the WWW-Authenticate header set to 'Basic'.
2) Create a custom authorizer that match your credentialand and retyrn response.
https://medium.com/#Da_vidgf/http-basic-auth-with-api-gateway-and-serverless-5ae14ad0a270
We are building a Front End Application which uses Azure AD APP to do single sign-on with Office 365.
To get Access Token using OAuth authentication process, we need to pass resource URI which can be
xyz.sharepoint.com -- to integrate with SharePoint site collections
xyz-my.sharepoint.com -- to integrate with OneDrive for business
outlook.office.com -- to integrate with outlook graph.windows.net --
graph.windows.net -- to use graph API for any search.
But to finish the single sign-on process, we need to fetch the user profile information at least email id is required. We were integrating with Onedrive for business in our Front End application.
So to get the user email, I can not get this information if I get the access token using resource xyz-my.sharepoint.com. I have to use xyz.sharepoint.com or graph.windows.net. So for our requirement, we have to fetch access token for 2 resources. It does not seem right, we had to maintain these access tokens along with refresh tokens to make these access tokens active.
Is there any other way to get an access token which can be used for all office 365 services OneDrive, Calendar, Mail, Outlook and Sharepoint?
Regards,
This is exactly the problem the Office 365 Unified API attempts to solve:
https://msdn.microsoft.com/en-us/office/office365/howto/office-365-unified-api-overview
Please take a look at the MSDN page above and let me know if you run into any issues integrating with the Unified API.
I hope this helps!
Shawn Tabrizi
I am developing a rather simple application that retrieves files from SharePoint using the REST Office 365 API. This is a batch job running in the background with no user interface so the following simple 2-step flow is what I'm doing:
(1) Requesting an Access Token from Azure AD (supplying client ID, client secret, resource, and grant_type=client_credentials)
(2) Invoke the SharePoint API (https://{base url}/_api/v1.0/Files) using the "Authorization: Bearer " as a request header .
That process seems pretty straightforward and sounds simple but I keep getting the following error:
401 Unauthorized
x-ms-diagnostics: 3001000;reason="There has been an error authenticating the request.";category="invalid_client"
Any idea what the problem is and how this can be resolved ? I have been stuck on this for days now. I would REALLY appreciate somebody's help with this. Thanks.
SharePoint Online doesn't yet support clients accessing it using app-only tokens (resulting from client credential OAuth2 flow). It only supports delegated token aka user+app tokens (resulting from authorization code OAuth2 flow).
So, if you wish to write a client application (web app or native client app) that accesses SharePoint online - it can only be on behalf of a user, and it must involve interactive authentication of the user - after the user authenticates - they will be shown a consent page where they need to consent to your application accessing the O365 API on their behalf.
Only Mail/Calendar/Contacts APIs (Exchange Online) support clients accessing them using app-only tokens - and they have turned on this support very recently. Read about client credential flow tokens with Exchange Online APIs here: http://blogs.technet.com/b/ad/archive/2015/02/04/using-azure-ad-to-build-daemon-applications-that-call-office-365-apis.aspx, http://blogs.msdn.com/b/exchangedev/archive/2015/01/22/building-demon-or-service-apps-with-office-365-mail-calendar-and-contacts-apis-oauth2-client-credential-flow.aspx
Hope this helps.
ps: OAuth2 client credential flow doesn't issue a refresh token
You will need an access token for the specific resource you are trying to access - in this case your sharepoint site for the Office365 REST Apis.
A good read on this can be found here: https://msdn.microsoft.com/en-us/library/azure/dn645538.aspx
Assuming your {base_url} is a sharepoint site, i.e., 'https://[site_name]-my.sharepoint.com
You can either:
(1) Initially get the access and refresh tokens using your client credentials plus a resource = {base url}
or
(2) Once you have the access and refresh token from the Azure AD resource, make a refresh_token call using:
client_id
client_secret
grant_type = 'refresh_token'
resource = {base_url}
refresh_token = [refresh token received from Azure AD
generate token response]
In this case you'll have 2 access tokens:
one that can be used for Azure AD requests
one that can be used for Office365 REST Api requests.
We could not/have not found a way to have a single access token be 'valid' for more than 1 resource.
Hope this helps!
I have an HTTP REST API that built for one of my company's devices. Ideally, the customer would have access to certain APIs, company employees would have more access, developers would have full access. Think of the device as a router - the customer can access certain settings, employees can come in and access more APIs than the customer for troubleshooting, and developers can access everything.
What are some good methods for implementing layered authorization on a REST API? Send an Authorization token or something in a POST so you can get an authorization cookie before using the REST API? I'm not familiar enough with web security to know a clunky solution from an elegant one.
you will send an authorization token in your Http Request header
Header.Add("Authorization", "bearer your_token")