ユーザー取得をUserAuthenticateのミドルウェアで回避しても、その後のRBACでユーザーがcontextから取れることを前提としてユーザーの権限をチェックする部分がある。(なお、AccessControlMiddlewareGenerator は scope パラメータによるrbac とユーザー自身の持つrbacの両方をチェックしている)

このフローによるTokenを使ったアクセス時はユーザーの権限チェックを回避し、(ユーザー同意なしで)事前にclientとしてアクセス可能なリソースの範囲を定めた上で、その範囲内のアクセスかをチェックするのが良さそう

https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.4 より

The client credentials (or other forms of client authentication) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server. Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server.

日本語(https://openid-foundation-japan.github.io/rfc6749.ja.html#anchor7)

認可範囲がクライアントの管理下にある保護されたリソース, もしくはあらかじめ認可サーバーとの間で調整済の保護されたリソースに制限されている場合は, 認可グラントとしてクライアントクレデンシャル (もしくは他のクライアント認証形式) が使用できる. クライアントがクライアント自身の権限においてに行動している (つまりクライアントがリソースオーナーである) か, クライアントがあらかじめ認可サーバーとの間で調整済の保護されたリソースアクセスを求めている場合, クライアントクレデンシャルが認可グラントとして使用される.

権限は
https://github.com/traPtitech/traQ/tree/efcd171bde834a5fac018f8124f34b58c3e36865/service/rbac/role
辺りでclient.goを作って、clientのロールを定義するイメージ

つまり、

もしくは明示的にユーザーに紐づいているかどうかに関するkeyをcontextに入れて、それをチェックする形でclient credentials flowであることを認識する形でも

なお、少なくとも

clinet credentials flowだと、アカウント失効されても引退者が現役時に作ったclientでリソース取得が可能になるというハックがありそう。引退時にそのユーザーが作成したOAuth clientは削除されるという運用をしていれば問題はない。

sysad系のサービスで使う場合は逆に途中で失効するとまずいけど、ユーザー失効のない@.traPアカウントで作成する方針になっていそうだから大丈夫そう

一応secretを見れていた人が引退することもあるので、年度替わりとかでsecret_idのローテーションを運用として行った方が良さそう

client は
https://github.com/traPtitech/traQ/blob/master/service/rbac/role/read.go
のうち、GetMeとかGetOIDCUserInfoといった自分自身に関する情報取得以外の参照系は許可する形が良さそう。