0
votes

I have an add-in in Outlook that has the ReadWriteMailbox permissions, but when I call getCallbackTokenAsync({ isRest: false }, callback), the token I get back has no signature. Basically, the token I'm getting is in the format xxxxxx.yyyyyy (instead of xxxxxx.yyyyyy.ZZZZZZ).

This appears to have just started happening in the last 2 days, however, the last time I worked on this project was about 4 months ago so it may have started happening sometime before now, but I'm just now seeing the error.

The EWS server is Office 365 (https://outlook.office365.com/EWS/Exchange.asmx).

I have also noticed that calling getCallbackTokenAsync has returned the same token, minus the signature the last 2 days.

1
Can you retry using isRest: true instead, is the token being returned still without the last part?Outlook Add-ins Team - MSFT
No, the rest token is valid. For a bit of context, the add-in ships the token to my backend which attempts to download the message from EWS and send it as an attachment to our ticketing system. If I use the malformed EWS token to download the message on the backed I predictably get an invalid token exception. But if I use the rest token, I get a 401.Allen Brooks
You will have to make a REST request with the rest token, the rest token will not work with an EWS request. Could you check what Fiddler returns after you call getCallbackTokenAsync, look for a call in fiddler to getClientAccessToken, is the response also missing the last part in Fiddler? Could you paste the Fiddler trace here if so. Also, what clients are you testing this from? Could you test 2 different clients (desktop, web, mac)? Are the results consistent across clients? Also, please share the build numbers of clients you are seeing this issue on.Outlook Add-ins Team - MSFT
Definitely. Since I'm only debugging this version locally, I can't test in OWA, but I have tested on the Mac client and I'm getting a well-formed token on that one. On the Windows machine, I tried to clear my Outlook cache by deleting the contents of %localappdata%\Microsoft\Outlook, but I'm still getting the same results. I don't see any calls in my Fiddler trace to getClientAccessToken on the Windows machine which indicates it's using a cached token. Where does the cached token live so I can delete it? The build number on the Windows machine is Version 1808 (Build 10730.20262 Click-to-Run).Allen Brooks
You will have to clear IE's cache. Try closing outlook, clear IE cache completely, reopen outlook, attach fiddler and then open the add-in to make the getCallbackToken request.Fiddler should now show a call to getClientAccessToken and get back the token.Outlook Add-ins Team - MSFT

1 Answers

0
votes

After almost pulling my hair out with this, I got it to work.

The original problem of getting an invalid JWT was the culmination of several problems (or suspected problems). The JWT was actually valid, although expired, but when I dumped the value out to the F12 tools console while debugging, the value was truncated to 1024 characters. I discovered that here: https://stackoverflow.com/a/27844847/4520915. The JWT was expired because it was using a token from the cache instead of requesting a new one from EWS. I fixed that by by closing Outlook, clearing IE's cache, and re-opening Outlook as suggested by the Outlook Add-ins Team - MSFT.

The issue now was getting EWS to accept the token because I kept getting a 401 error ("Access is denied. Check your credentials and try again."). I discovered this was because I was running the add-in and the subsequent Azure Function that it utilizes on localhost. Apparently, EWS doesn't like localhost. After deploying the add-in to a development environment, we all good.

Thanks to the Outlook Add-ins Team - MSFT for their help.