ritouです。
こういう質問がXのDMで来ました。
「Webアプリケーションのセッション管理は認証ですよね？ritouさんの考えでは認可であると主張しているように見えます。(以下省略」
Publicな質疑応答は他の人の役にも立つと思うので、こういう質問は匿名のマシュマロでください。
話を戻して、自分はアプリケーションのセッション管理はアクセスコントロールに関する仕組みであり、「誰か」を確認するためのAuthenticationというよりは「誰がどのような権限を持ってリソースアクセスしようとしているかの省略系」というAuthorizationの部分に当たると考えています。
この考えに至ったのが10年前です。相変わらず雑な記事を書いています。
WebアプリケーションのログインURLのあたりが、ユーザーの認証を行います。ここがAuthenticationですね。
そして、ブラウザやSPAなどに対してHTTP Cookieもしくはアクセストークンとしてセッション情報を表す文字列を渡します。その後、ブラウザはアプリケーションへのアクセスの際にCookie、SPAならばバックエンドサーバーに対してアクセストークンを付与します。それを受け取ったアプリケーションやバックエンドサーバーはそのセッション情報の内容に基づいてリソースアクセスを許可するか判断し、リソースを返します。この辺り、というかログインフロー全体がAuthorizationの処理となっていると考えます。
前述の記事へのブクマではこんな意見が見られました。
クッキーはid_tokenのようなもので、誰であるかを示しているだけだと思う。結局認証じゃないのかな。どんな操作ができるかはアプリが決めているわけだし
OAuthのリソースサーバーがアクセストークンからリソースオーナーのIDを取得してそれを利用してリソースアクセスを許可するか判断(リソースオーナー自身のリソースなら書き込みもOKとか)すると考えると認可とも言えるでしょう。
どんな操作ができるかはアプリケーションが決める、の部分もポリシーをどこで定義するか(PDP=Policy Decision Point)、どこでアクセスコントロールを実現するか(PEP, Policy Enforcement Point)の話になるでしょう。Cookieやトークンが有効かどうかの判断の後にその中に含まれるユーザーIDで...の判断が行われるように複数のポリシー参照が行われるのです。
権限の認可ってセッションに関連付けられた何らかのIDを元にアプリケーションレベルで制御するものでは？
上述の通り、アプリケーションレベルで制御するものであることは否定していません。
cookieに認可に関連した情報を含める場合は明確に表題のとおりだと思うけど、実際はcookieには認証情報のみを含めてリクエストの度に認可を行うほうが（クッキー発行後に権限を変えるケースを考えると）実装／運用が楽
これも複数のポリシー参照、判定が行われる中でどの情報が利用されるかみたいなところと捉えられます。
そもそもセッション情報に含まれるのはユーザーIDだけではないですよね。有効期限、認証方式や認証強度、認証時の環境などを直接含んだり、セッションDBのようなところで管理しておいてアプリケーションが参照できるようにしておくこともあるでしょう。決済機能などの設定では認証情報によるポリシー参照が行われることはイメージしやすいかと思います。
OAuthやOIDCのような複数アプリケーションのID連携の前に、単一アプリケーションの処理の解像度をあげてみるのはいかがでしょうか。
ではまた。