On our desktop add-in for Outlook, once we receive a token for the Microsoft Graph API we make a call to retrieve the user's email message from the following endpoint: https://graph.microsoft.com/v1.0/me/Messages/[message_id]
This call to the Graph API is coming from our server, so it shouldn't matter that the add-in UI is running in the browser or in the Outlook client. However, we're seeing that - sometimes - when running from the Outlook client, that the request from our server for the Message gets a 404 response.
I have captured the url and token of both requests from the web browser add-in and the Outlook client add-in, and tested each manually. Both api URLs were the same, and both tokens that were generated (one from the OWA add-in and the other from the Outlook client add-in) worked successfully when I tried them manually with Postman.
Any ideas why the requests from the Outlook client add-ins fail while the web-based add-in requests are successful?
stmcallister--I'd like to restate my understanding of your flow a bit. In your question, you mention that your calls to the Microsoft Graph are coming from your service. Am I right to assume that your add-in is presenting the OAuth flow for your service's Application Id, collecting a Token on its behalf, and then flowing the Token back to the service via an API call? Do you flow Id, Access, or Refresh Tokens to your service?
If this is the case, then as you say it certainly shouldn't matter where your add-in is hosted at runtime. However, it's possible that your Tokens (specifically their claims) are slightly different based on the original login context (Browser vs. Office).
In either case, a 404 is an unfortunate response if there's a Token issue. If you can provide more details about the problem requests, then we can look into it.
Thanks,
-TimMc
Related
This question might be a duplicate of this one but I believe it was not properly addressed and I have come up with the same concern a year later.
I'd like to use my own oauth provider authentication flow, and I'd like to understand what's the best user flow for getting the token from my server.
According to the documentation, we need to use the displayDialogAsync method to open the oauth screen, which will send the authentication code to the backend, which it can decode and create a token that can be used for the Office add-in frontend.
However, there's no indication on how the backend can send this token to the frontend. Since setting a token cookie will not make it accessible from the add-in side. It seems the only way to grab it is by redirecting from the server to https://localhost:3000/oauthResult/index.html?authToken=XXXX. And that route can somehow store the token somewhere and then close the dialog.
So my main two questions are:
How to safely send the access token from the backend to the frontend without using a redirect with a cookie
Where to safely store within the Office Add-in ecosystem so that it can be picked up both by desktop and web clients? I know that I shouldn't use the Settings object to do so.
I tried using a redirect from my backend to my add-in frontend with the auth token set in a cookie, but that cookie was not available to be read from the add-in side later on.
For your inspiration, see Caching in MSAL. MSAL.js is the Microsoft Authentication Library for JavaScript. MSAL.js is using the Web Storage API and can be configured to use either sessionStorage, localStorage or memoryStorage. As the article describe, the choice between different storage locations reflects a trade-off between better user experience vs. increased security.
There are three methods to send Email by Outlook in WEB.API Core .
I can use directly JSon query for Microsoft Graph API or for
Outlook API directly;
I can use library Microsoft.Graph;
I can send in WEB.API Core from program Outlook in the
computer .
In first two situations I must manually with browser log in.
Third way is does not satisfied me cause at server can not be program Outlook .
Is it possible to get Authorization and Authentication without browser, from my server directly ?
You can use the Client Credentials Grant Flow , in this scenario , your web api will call Microsoft Graph to send emails with their own identity and not on behalf of a user ,then no login process :
Get access without a user using Microsoft Graph
My Solution for send Email like from Outlook is I must interact with Exchange Web Service . So this is that what I looking for . This is the four's way for interaction with Outlook . And the best incarnation for this is packet Microsoft.Exchange.WebServices.NETStandard .
I have a JAX-RS application deployed under tomcat and a mobile app.
I would like to know how to make the webservice usable only by the mobile application, in other words, allow access only for a given application
When a request comes in across the internet, there's not really a safe way to be sure what application sent the request. Applications can identify themselves however they want. You could, if you want, attempt to hide credentials in your application, somehow, and have it log in with those credentials. But if anyone discovers those credentials, they can write a program that uses them to pretend to the your application. The problem is that you cannot count on any control over the client system. The client system can always be altered to pretend to be something it is not.
From my perspective, you can add username/encrypted password in the invoke request, and then compare it with the ones saved in the server side
If you really want to, you could implement some form of cryptography. For example, the JAX-RS service can send a 401 forbidden and provide a nonce for the client to sign with its private key, and then send back to the server in the Authorization header. Otherwise, stick to HTTP authentication. If you are communicating via HTTPS, you should be fine with basic auth.
I am developing software that will be used on small system at clients. The software is fetching Google calendar events from whatever Google account the client adds to it. The thing is that Googles API requires an secret key to work. As it is now, the system is working but the key is directly in the code, which means that the end user will be able to see it.
Firstly, is this a problem? I guess that because the key is "secret", there will be bad if a client can see it. Second, if this is bad, how should I do to avoid this? Is it even possible?
I should not be a problem since the key alone is not enough to generate an access token. You also need a refresh token or authorization code for that.
One risk is that, using the key, one of your clients (Alice) builds an OAuth authorization URL and tricks another of your client (Bob) into authorizing Alice's custom application to get calendar data. That problem only occurs if you're using the "installed application" workflow with the "urn:ietf:wg:oauth:2.0:oob" redirect URI.
If you want to avoid this problem, you can decide to host a web service that will handle the authorization for the embedded system. This web service will hold the client secret, and will receive call from your systems to either request authorization from a customer or refresh a token. Of course now you need to secure this web service, but you can probably do that with a customer-specific set of credentials. That way the only thing on the customer's premises are his specific credentials to access the webservice, nothing else.
I'm currently exploring the (Academic Licensed) Office365 API via oAuth access_tokens and have succeeded in retrieving a simple OneDrive folder list via the SharePoint API using access tokens, as a proof of concept.
But this seems to work only for users that are in the Azure maintenance domain that's NOT SSO enabled to our on-premise ADFS server.
The domain that is SSO enabled to our own ADFS server succesfully gets logged in on acquiring the oAuth code and I get a genuine access_token while trading in this code. But using this access_token to retrieve a simple folder list for the user results in this error instead of a folderlist.
{"error_description":"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}
Wich I can't check since I'm not in control of the Azure Sharepoint server.
Did anyone succeed in using the Office365 API icw SSO enabled domains/users?
You'll struggle with an ADFS setup. Any code I've written relies on managed accounts only (i.e. those accounts with a UPN ending with onmicrosoft.com). Each synchronised user from on-premise will have a matching onmicrosoft.com secondary identifier which you should use instead.