MS Graph 401 .. claims in token?

0
votes

Trying to post events to user calendars for our organization. Getting a 401 error.

Azure admins created an app/user, and gave permissions

Delegated Graph Permissions: Calendars.ReadWrite

App graph permissions: Calendars.ReadWrite

I can connect to the OAuth token generation end point, and retrieve a token. Using that token, I can't send my JSON payload and create a series of calendar events, I get a 401. The JSON is known good - I can copy/paste it into the graph explorer tool and get correct results.

I've examined a generated token using jwt.ms and I'm not seeing anything related to permissions, calendars, etc.

Our Azure logins use empIDnumber@example.com and I've been told that is what our userPrincipalName is

I've tried changing the URL end point with no change-

/v1.0/users/empIDnumber@example.com/calendar/events

and

/v1.0/users/empIDnumber@examplecom.onmicrosoft.com/calendar/events

Where should I look next?

1
microsoft-graph-apimicrosoft-graph-calendar
could you post your decoded jwt content? that would help. – Chris Johnson
@ChrisJohnson - i do have an expired token copy/pasted, but since it contains info like tenant id and such i'm not sure of what security implications there would be. Suggestions? – ivanivan
if you decode it using jwt.io and copy/paste the payload section + redact any PII (emails, names) then there isnt anything that is "secure" in there" Tenant Id can be freely found by anyone outside the org and isn't secure data. But if you are worried redact it. – Chris Johnson
agh. can't find old tokens. waiting for token to expire before posting – ivanivan
so long as you don't post the encoded jwt and only post the payload there is nothing anyone can do with the token :) It needs the signature etc... for azure to accept it. – Chris Johnson

1 Answers

0
votes

Solved.

Slight typo in the content of the JSON I was sending, was only able to find it by doing the POST using postman. Java was throwing an exception, not showing the returned string as well as the exception message, but postman showed the returned JSON with content regarding malformed date/time.

Still got 401 exceptions though, so The Fix Part II was to add an Accept-Encoding property set to application/json to my http client request options array.

Still no claims showing up in my tokens, but that is a non-issue apparently.