这取决于您引用的资源以及控件的粒度。
OAuth 2的作用域是您将在授权服务器返回的访问令牌中检查的作用域。访问令牌中的任何作用域都代表允许用户本人进行的访问以及她代表她同意您的应用进行的访问。资源服务器需要在允许访问协调资源之前验证访问令牌中的作用域是否正确。
OAuth流程的工作原理是，您的应用在包含特定范围的情况下发出授权请求。
授权服务器应该消除用户不允许的任何范围，无论他们是否同意，然后询问用户是否同意剩余的范围并进行身份验证。
有时候，“请求同意”部分是隐式地完成的（不太理想），此外，它可以是全部完成，也可以是不完成，或者是允许用户挑选。
在用户成功进行身份验证后，您的应用会收到一个访问令牌（跳过此处不相关的一些详细信息），其中包含与用户已同意的访问权限相对应的范围。
当访问令牌发送到资源服务器时，在允许访问之前，它应该检查该令牌是否在其令牌验证中具有所需的范围。
因此，如果你在谈论Google上的资源，Google确实有一些范围，你可以在授权请求中包括这些范围，并且用户必须同意。然后，它们应该在访问令牌中返回。作为资源服务器，Google将拒绝访问，如果在需要访问令牌的调用时它们不存在的话。有时候，Google的范围可能无法提供更细粒度的控制。不过
如果你在谈论使用不同的资源服务器，那么是的，你需要自己实现Authz部分。如果你不需要太多的控制，你可以隐含地将同意与他们是否成功地通过了Google的身份验证相关联（最好是告诉用户情况就是这样），但这将超出OAuth的范围，您将失去它为授权提供的大部分安全性。否则，您需要一个了解您的资源服务器并已在资源服务器和您的应用程序之间建立了相互信任的授权服务器。

但是如果我需要在我的应用程序中实现AuthZ（例如，为了确保当前用户只访问属于他们的资源），我必须自己做，对吗？
你在这里基本上是正确的。OAuth2可以帮助你，但你需要自己的授权服务器。然后，你的应用可以使用OAuth2从授权服务器获取访问令牌，并使用令牌调用你的API。你的API应该实现适当的授权检查（如你所提到的，例如，检查访问令牌中的用户是否与资源的所有者匹配）
这里的经验法则是，用于调用API的访问令牌应该来自与该API相关联的服务器。因此，要调用Google Calendar的API，您将需要来自Google的OAuth2访问令牌。要调用您自己的API，您将需要由服务器颁发的访问令牌。
正如您提到的，您可以利用OIDC（即JWT ID令牌）使用Google对用户进行身份验证。身份验证后，您将颁发访问令牌，允许应用调用您的API。