APIのクロスアカウントアクセスについて調べていて、アクセス許可についてしっかり理解する必要を感じたので自分なりにまとめます。
アクセス許可
AWSのリソースも、OAuthのAPIと同じように「リクエストしたユーザー・ロール（＝プリンシパルエンティティ）が認証されているか」「アクセス許可を持っているか」を確認します。
私がよく躓くのは、この「アクセス許可を持っているか」の部分のようです。
ポリシー
アクセス許可は、IAMユーザー・ロールにアタッチされているポリシーと、リソースにアタッチされているポリシーの両方を重ねて評価して判断されます。
ちなみに...
* アイデンティティ・リソース以外にも４種類のポリシータイプがあるらしい。
参考：ポリシーとアクセス許可
* ポリシー以外のアクセス許可もあるらしい。例えば、ポリシーの条件にタグを含めるなど。
参考: ポリシーを利用したアクセス制御
大体の場合はアイデンティティベースのポリシーを設定するだけで済んでいると思いますが、クロスアカウントアクセスの場合はリソースベースのポリシーを設定することも必要になることがあります。
アイデンティティベースとリソースベース
共通するポイント
どちらもJSONです。あ、CloudFormationで作成する場合はYAMLですね。でもAWS上ではJSONです。
文法もだいたい同じです。Resourceに対するActionのEffect（Allow/Deny)のリストをStatementとしてリストにする、ってとこですね。
アイデンティティベースの場合はPrincipal要素は指定してはいけないようです。
参考： IAM JSONポリシー言語の文法
参考: AWS JSON ポリシーの要素:Principal
異なるポイント
アイデンティティベースのポリシーでは管理ポリシーを作ることができますが、リソースベースだとできません。つまり、リソースに対して似たようなポリシーを適用する場合は、リソースごとに同じポリシーをコピペする必要がある、ということです。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
迷ったポイント
リソースとしてのIAM Roleにもリソースポリシーがあります。
例えばECSのサービスがIAM RoleとしてS3にオブジェクトをアップロードする場合、そのRoleに引受（Assume)可能かどうかをリソースポリシーとして設定するわけですね。
クロスアカウントアクセス
要するに、IAM側でもリソース側でもアクセス許可をする必要があるようです。