I have an EWS token and attachment details as payload sent from an Outlook add-in. I am trying to use the Microsoft Graph API to fetch the content of the attachment in base64 format and save it in an AWS S3 Bucket.
My plan is to use the following API endpoint:
https://graph.microsoft.com/v1.0/me/messages/${itemId}/attachments` (/${attachmentId})
However, when I try to use the EWS token as the access token for this request, I get an "Access token validation failure. Invalid audience." error. How can I obtain a valid access token for this request and successfully fetch the attachments?
I tried using npm packages like node-ews and ews-javascript-api.
I tried using the above endpoint and token-exchange grant type too.
Alternate (better) methods are also welcomed.
EWS and Graph API are different technologies. You can't use EWS token for accessing Graph API. To access data through Microsoft Graph, your application will need to acquire an OAuth 2.0 access token, and present it to Microsoft Graph in either of the following options:
The HTTP Authorization request header, as a Bearer token
The graph client constructor, when using a Microsoft Graph client library
Use the Microsoft Authentication Library API, MSAL to acquire the access token to Microsoft Graph.
Read more about that in the Best practices for working with Microsoft Graph article.
Related
I automate tests and I need to send a report to my squad. The company uses Microsoft tools (Outlook, Teams, etc.)
I'm trying to send a message in a chat using the Microsoft Graph API and Postman before I code it.
When I'm using the Graph Explorer, I can access the data that I need. But when I'm doing using Postman, my access token validation fail.
It's possible to call Microsoft Graph API using Postman? Where I get the right Bearer Authorization (I'm getting the Bearer token in a Microsoft Teams Login)?
Yes, it is possible to call Graph api from postman. You would need to get the access token with suitable permissions required to call your graph api. Please go through Get access token to get the appropriate token and make a call. Please let me know if you need any further help.
I have three applications: REST API with Resource Server, Authorization Server and javascript client on VueJs that should use REST Api. Problem in using access token that I get after authorization. First I decided to use local storage or cookie for storing access token, but as I read It's not secure. It's recommended to use cookie with httpOnly, but I can't to access from js. Addition token in url params as well not right way. So what I should to do for using my Rest Api? I'm using Authorization Code grant flow.
When you have a Javascript client, the client itself should act as an OAuth2 client.
Meaning, the server is not what gets the token. The client, the javascript application in the browser, will fetch the token from the authorization server.
You achieve this by using a grant type called implicit.
In this grant type, there is no client_secret, but you must have a valid client_id. You will also not receive a refresh token. But you can receive access tokens and id_token (if you have an OIDC server).
Your question hints at you doing a server side grant (authorization_code,password,etc) and then sending that token to the javascript client. This would be incorrect.
For a great description of OAuth2, we have published this video: https://www.youtube.com/watch?v=u4BHKcZ2rxk
Your JavaScript application would do this:
Do I have a valid token? No
Start implicit grant
Receive token from authorization server
Store token in memory var token = ....
Use the token to invoke API endpoints on the server
Repeat step 5 until token is no longer valid
Go back to step 1
Next step for you is to watch the video and learn more about implicit grant type
As you already guessed, going down the road of getting a token on the server and then sending it to a non secure client exposes your applications in ways you probably do not want.
I have a working oauth2 application using v1.0 of Azure REST API. I am able to acquire access token via ADAL library for Java and no problem accessing their resources.
However, I wanted to know if there is a way to use this same token in order to let Office365/Outlook users to login on a web browser without entering a password ? Something like https://outlook.office365.com/token=abc..
This will help us to let users SSO on different devices without typing their passwords.
Technically, yes you can. You can try to leverage Microsoft Graph API to achieve your requirement.
Add the permission of Microsoft Graph in your AAD application, refer to https://graph.microsoft.io/en-us/docs/authorization/auth_overview for more info.
Follow OAuth2's Authorization Code Grant Flow to generate an access token, or leveraging your ADAL, please refer to https://graph.microsoft.io/en-us/docs/authorization/app_authorization for details.
Set the access token in the request header the same as you call Azure Rest APIs.
GET https://graph.microsoft.com/v1.0/users/john.doe#contoso.onmicrosoft.com HTTP/1.1
Authorization : Bearer <access_token>
For outlook APIs, you can refer to https://graph.microsoft.io/en-us/docs/api-reference/v1.0/resources/message for more info.
Im writing a application for outlook, front-end Angular, backend Web API.
I'm successfully getting access-token using adal in front-end, sessionStorage is:
adal.access.token.keyxxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09:"Access-token"
adal.error:""
adal.error.description:""
adal.expiration.key:"0"
adal.expiration.keyxxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09:"1482073764"
adal.idtoken:"access-token"
adal.login.error:""
adal.login.request:"http://localhost:8080/"
adal.nonce.idtoken:"xxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09"
adal.session.state:"86xxxxxd-xxxx-480b-xxxx-34923xxxx918"
adal.state.login:"9axxxxxx-xxxx-xxxx-xxxx-360xxxxxx94"
adal.token.keys:"xxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09|"
adal.token.renew.statusxxxxx6b-xxxx-xxxx-xxxx-376xxxx9c09:"Completed"
Now i'm sending access-token to backend, and i want to get messages from outlook API, but how can i do it.
Searched for outlook REST api, and tested using POSTMAN, but not working.(401 error)
Get https://outlook.office.com/api/v2.0/me/messages
Authorization: Bearer access-token
Accept: application/json
Any suggestions on how to do this?
Thanks in advance.
It looks like you are trying to complete the on-behalf-of flow.
This is where a front-end API gets an access token to a middle tier service, which subsequently gets an access token to a back-end API. Let's assume that the token from the front-end to the middle tier has user context. You are able to get a token from the middle tier, to the back-end using the same user context, by requesting a new access token using the original access token.
Here are more details on the flow: Find the section titled Delegated User Identity with OAuth 2.0 On-Behalf-Of Draft Specification
Here is a code sample integrating this flow:
https://github.com/Azure-Samples/active-directory-dotnet-webapi-onbehalfof
Just to note, in this specific case, that the 401 error implies that you do not have the correct permissions for calling and accessing the API you want. Can you make sure you have selected the right permissions for the resource you want to access, for the client that you are accessing it with?
I hope this is what you are looking for!
I have a Web API and AngularJS client. The API is using default authorization provider given by visual studio to generate the token on token request with grant_type 'password'.
The AngularJS client is able to get the bearer token from Web API by calling the token endpoint with credentials and later passes this token to perform authorized requests in the API.
When AngularJS sends the token on any authorized API call, how is Web API able to validate the token? Where does the token get stored?
I checked in Identity tables in SQL server, I could not find any fields to store this token information. I checked in the configuration file, it is not stored there either. Could you please help me in understanding this concept?
Raj,
By default the token is not stored by the server. Only your client has it and is sending it through the authorization header to the server.
If you used the default template provided by Visual Studio, in the Startup ConfigureAuth method the following IAppBuilder extension is called: app.UseOAuthBearerTokens(OAuthOptions).
This extension coming from the Microsoft.AspNet.Identity.Owin package makes it easy for you to generate and consume tokens, but it is confusing as it is an all in one.
Behind the scene it's using two Owin middlewares:
OAuthAuthorizationServerMiddleware: authorize and deliver tokens
OAuthBearerAuthenticationMiddleware: occurs at the PipelineStage.Authenticate, read the authorization header, check if the token is valid and authenticate the user.
To answer you questions WebAPI is able to validate the token thanks to the OAuthBearerAuthenticationMiddleware, it will ensure that the token sent through the authorization header is valid and not expired. And the token is stored only by your client, if the client loose it, it will have to request a new one.
I advise you to get deeper in the OAuth protocol, and instead of using the extension UseOAuthBearerTokens, take a look at UseOAuthAuthorizationServer and UseOAuthBearerAuthentication, it will help you to better understand how it works.
The generated token will most likely be a JWT (Get Started with JSON Web Tokens), which means it's a self-contained token that is signed with a secret/key that only the server or other trusted parties know.
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.
(emphasis is mine)
This means that when receiving the token the server can ensure that:
the token was originally issued by a trusted party by checking that the signature is valid.
the token is associated with a user that has permissions to perform the following request because the token itself contains information that uniquely identifier that user.
This type of approach has the side-benefit that the server does not need to keep track or store the generated tokens in order to validate them at a later time. Since no one else has the secret/key you can't modify the token without making the signature component invalid, which would then mean a faked token would end up being rejected by the server.
This is a simplified description of what happens, there are much more details around how to issue and validate tokens correctly. You should read the OAuth2 and OpenID Connect specification to learn more on the subject of token-based authentication.
Also note that I assumed a JWT token because it's the format that currently has the most widespread adoption to accomplish scenarios like these ones and it's also the token format to use in conjunction with OAuth2 and OpenID Connect. However, it's still possible to achieve the same with other token formats.