Office365 API - 访问另一个用户/房间的日历 [英] Office365 API - Accessing another users/room's calendars

查看:22
本文介绍了Office365 API - 访问另一个用户/房间的日历的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试构建一个可以访问组织的所有日历(用户、房间等)的应用程序.

目前,我的身份验证流程将代表租户用户登录并使用刷新令牌来访问所需的资源.一旦我提出请求:

https://outlook.office365.com/api/v1.0/users/{room-resource@email}/events

我的应用程序以 401

响应

从我的收集来看,此流程似乎仅限于单个用户的范围.尽管租户管理员应该有权查看任何房间资源,但从技术上讲,房间本身就是一个用户,因此 API 会以禁止的错误进行响应.现在似乎正确的流程是租户管理员必须使用新的 服务 OAuth 流程.>

阅读这篇文章,似乎 API 正在使用 OAuth 客户端凭据授予类型(仅限应用程序令牌).我现在必须使用 /oauth/tenant-id 而不是使用 /oauth/common 端点,我可以通过 code+ 中返回的 JWT 令牌检索它id_token 响应类型.这引出了我的第一个问题:

使用 OpenID 流程是最初检索租户 ID 的唯一方法吗?

接下来是事情对我来说有点模糊的地方.

我们现在必须生成 X.509 SSL 证书并将指纹/值上传到我们的 Azure 应用程序清单.很简单.

然后根据Office 365 Rest API - Daemon Week authentication<中的讨论/a> 我们构建了一个特定的 JWT,对它进行 base64 编码,并使用我们的证书对其进行签名.

我实际上还没有完成这里的最后几步,但我会尽可能发布我的结果.我只是确保我似乎正在遵循我尝试访问的资源的正确程序.我知道服务令牌是一个相当新的功能,不幸的是我不得不在 Stackoverflow 上找到发送签名 JWT 的流程,而不是 MSFT 官方文档......

我还注意到,由于我们使用的是客户端凭据流,因此我们不会在响应中收到 refresh_token.所以对于我的最后一个问题:

当访问不同的资源(即图形 API/Office365 API)时,我是否只是使用我的签名请求而不是 对多个资源使用刷新令牌?

如果我的大致方向是正确的,请告诉我!非常感谢任何帮助.

解决方案

聚会迟到了,但我也一直在努力解决这个问题,这就是我的发现.

进入 Office365 的 OAuth 路由将只允许您访问自己的日历.应用程序在 Azure 中拥有什么权限或您为每个用户配置什么都无关紧要.这是 API 的限制.

MSFT 在对此 StackOverflow 问题的评论中证实了这一点:
Office365 另一个 API - 管理员访问用户/房间的日历事件

但是,您可以使用基本身份验证来访问其他人的日历.

1) 配置主要"用户(您进行身份验证的用户)以访问次要"用户(拥有您要查看的日历的用户)帐户.为此,请进入次要用户的 Exchange 属性 -> 邮箱委派并授予主要用户的完全访问权限.

2) 将身份验证与请求一起传递给 Office365 API:

3) 如果您做对了所有事情,您现在就拥有了二级用户的活动!

I'm attempting to build an application that will have access to all of an organization's calendars (users, rooms, etc).

Currently my auth flow will sign in on behalf of a tenant user and make use of refresh tokens to access needed resources. As soon as I make a request to:

https://outlook.office365.com/api/v1.0/users/{room-resource@email}/events

My application is responded with a 401

From my gathering, it seems that this flow is limited to a single user's scope. Although the tenant admin should have permission to see any of the room resources, the room is technically a user itself so the API will respond with a forbidden error. It now seems that the proper flow is a tenant admin must grant permission to my application using the new Service OAuth Flow.

Reading through this post it seems that the API is making use of OAuth client credentials grant type (app only tokens). Instead of using the /oauth/common endpoint I now have to use /oauth/tenant-id which I can retrieve via the JWT token returned in the code+id_token response type. This leads to my first question:

Is using the OpenID flow the only way to initially retrieve the tenant ID?

Next is where things get a little fuzzy for me.

We now have to generate an X.509 SSL certificate and upload the fingerprint/value to our Azure application manifest. Easy enough.

Then according to the discussion in Office 365 Rest API - Daemon week authentication we build a specific JWT, base64 encode it, and sign it with our cert.

I haven't actually gotten to the last few steps here but I will post my results when I can. I'm just making sure that I seem to be following the correct procedure for what resources I'm trying to access. I know the service tokens are a fairly new feature, it's just unfortunate that I had to find the flow of sending the signed JWT on Stackoverflow rather than official MSFT documentation...

I also noticed that since we're using the client credentials flow we will not receive a refresh_token in the response. So for my final question:

When accessing different resources (ie Graph API/Office365 API) do I just get a different access token for each resource using my signed request instead of using refresh tokens for multiple resources?

If the general direction I seem to be going is correct let me know! Any help is greatly appreciated.

解决方案

Late to the party, but I've been fighting thru this too, and here's what I've found.

The OAuth route into Office365 will only allow you to access your own calendar. Doesn't matter what permissions the app has in Azure, or what you configure per user. It's a limitation to the API.

This was confirmed by MSFT in the comments to this StackOverflow question:
Office365 API - Admin accessing another users/room's calendar events

You can, however, use Basic Auth to gain access to another person's calendar.

1) Configure the "Primary" user (the one you authenticate with) to have access to the "Secondary" user's (the one with the calendar you want to view) account. To do this, go in to the Exchange Properties for the Secondary user -> Mailbox Delegation and give Full Access to the Primary User.

2) Pass the authentication along with the request to the Office365 API:

<?php
$username = 'primary@user.com';
$password = 'mypass';
$URL = 'https://outlook.office365.com/api/v1.0/users/secondary@user.com/events';

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL,$URL);
curl_setopt($ch, CURLOPT_TIMEOUT, 30);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_HTTPAUTH, CURLAUTH_ANY);
curl_setopt($ch, CURLOPT_USERPWD, "$username:$password");

$status_code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
$result=curl_exec ($ch);
curl_close ($ch);

print_r($result);

?>

3) If you've done everything right, you now have the events for the Secondary user!

这篇关于Office365 API - 访问另一个用户/房间的日历的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆