OAuth 2.0 は形式を定めていません。不透明なトークンは認可サーバーへの問い合わせ（トークンイントロスペクション、RFC 7662）で検証するため、即時の取り消しが可能です。JWT のアクセストークンはローカルで検証します。RFC 9068 はそのプロファイルとして、typ を at+jwt とし、必須クレーム iss、exp、aud、sub、client_id、iat、jti に加えて scope を定めています。
リソースサーバーは署名だけでなくオーディエンスとスコープも確認しなければならず、DPoP や mTLS による送信者制約（sender-constrained）がない限り、トークンをベアラー認証情報として扱わなければなりません。クライアントは、アクセストークンがたまたま JWT であっても、形式が変わる可能性があるため、不透明なものとして扱うべきです。