ritouです。
Digital Identity技術勉強会 #iddance Advent Calendar 2024 というのをやっておりまして、この記事を持って完結となりそうです。
ご協力、閲覧していただいた皆様、ありがとうございました。
本日書いていただいた記事でちょっと思い出したことがありました。
コメントしているOAuthどうこうとは別です。そして、この記事についてdisりたいわけでもありません。普段から素行が悪くてそう思われたら申し訳ないです。
認証と認可の関係よく混乱する件
この辺りですね。
ここで、「認証なのにOAuth？」と思った方。鋭いです。一般的には、認証連携につかうのがOpenID Connect(OIDC)であり、OAuthは認可のために使うプロトコルで、これを混同してOAuth認証と言うと、OAuth警察が飛んできます。ですが、デバイスフローにおいては、テレビやゲーム機などの外部デバイスに対して、アカウントの一部機能を使うことを認可することになります。誤解を恐れずざっくり言えば、テレビやゲーム機にデバイスフローでログインしたとしても、アカウントの全権限は委譲されません。アカウントの大事な機能（パスワード変更など）にはアクセスできないと思います。なので、認証ではなく認可であると理解しておいてください。
読者として、認証方式の整理だったところに認可ですって出てきたらちょっと混乱するかもしれないなというところで、リソースアクセスという括りの中で認証と認可の関係ってどんなもんなのかについて軽く整理しておきたいと思いました。
リソースアクセスのキーワード: 認証、認可、監査
タイトルの通り "リソースアクセスというのは認証+認可(+α)で成り立っている" というところです。αは確か監査ですが、一旦おいておきます。
認証
認証は、「あなたは誰か？」 を確認するプロセスです。クレデンシャルを用いてサービスに登録しているユーザーであることを確認します。
認可
認可は、「あなたが何をする権限があるか？」 を判断するプロセスです。ユーザーがリソースや機能にアクセスしていいかを判断し、制御します。一般的に、"ACL", "RBAC", "ABAC", "ReBAC?"などのルールやポリシーに基づいて実行されます。
いわゆる "ログイン" という機能において、これらの認証と認可の両方が行われていることに留意する必要があります。どちらも行われる場合は認証、認可の順となることが多いでしょうが、認可のポリシーによって認証機能と密結合、疎結合なシステムのどちらもあり得ます。いわゆるセッション管理によって認可のところだけ行われているように見えます。逆に認可のポリシーがゆるければ認証しかしてないように見えることもあると思います。
ID管理やリソースアクセスについて考える時に頭に入れておきたい部分だと思います。これをベースにして単一アプリケーションにログインしてデータにアクセスする時にどのような処理が行われるか、OAuthで認可サーバーがアクセストークンを発行、それを持ってクライアントがリソースアクセスを行った時にどのようにどこで認証と認可(アクセス制御)が行われるかを考えてみましょう。
ではまた。