認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）

みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o

[mak_in]

認証は外部のサービスで、認可は自前で、が楽な印象。認可は結局、アプリの要件を整理しないと決まらないので、外に出してもなぁ……って感じで、そうしてる。

[NOV1975]

認可や権限管理はどうしてもアプリ側の要件になる事も多いから、下手に一元管理すると処理コストがや変更コストが掛かるよな。それに負けない設計するとシステムサイズに対してそこにかかる工数が大きくなりすぎる

[pcrd]

“認可の対象が「誰」なのかは、認証にIdentity Provider（IdP）を使う 認可はアプリケーションに閉じた方がシンプル（専門の認可サービスを作るより） 認可ロジックはアプリケーションロジックとは分離する”

[usadamasa]

いつもお世話になっております｡

[roshi]

基本はやはり埋め込んでいくしか無いのかなぁ。。

[NetPenguin]

めっちゃ為になった。 認可というものの枠組みとパターン化。

[rgfx]

はい

[ya--mada]

なるほ