認証と認可の話は難しいが、ようやく像を結ぶようになった。
「Drupal 9 おいしいレシピ集 2」に関連して「OpenID connect とDrupal」という記事でも書いたが、認証と認可とリソースが同じサーバーで動いているとどれが何を実現しているのかわからなくて混乱してしまう。
（上の「今すぐ購入」から書籍をお買い上げいただけると幸いです。）
DrupalをOAuth2で認可サーバーとして構成すると、どうしてもDrupal認可サーバーにログインしないといけない。OAuth2では認証を行う（あるいは認証サーバーに依頼する）時に認可サーバーにcallbackを行うように構成することで安全性を確保している。書籍「Drupal 9 おいしいレシピ集 2」の5章「Drupal で理解するOAuth 2.0」では、パブリックなURLを持たないcallbackサーバーを指定して呼び出してauthorization codeを取得して、そのコードを元にAccess Tokenを取得、そのAccess TokenでリソースサーバーにRESTでコンテンツ作成を行っている。OAuth 2.0のフローを理解する上で、とてもわかり易いのだが、本来はクライアントがcallbackの機能を行うのではなく認可サーバーが認可の過程で認証サーバーを呼び出し、認証サーバーからのcallbackでAccess Tokenを作成してクライアントに発行しないといけない気がする。アプリがセッションを持たないとすると、そもそも認証ができない。OAuth2 Clientで代用できるようだが、ログインが実装できるかどうかはわからなかった。
いろいろ調べていたら、Drupal REST & JSON API Authenticationというモジュールがあることに気がついた。このモジュールのOAuth 2.0 Authentication機能を利用すると、アプリでユーザー名とパスワードをPassword Grant設定で埋め込んで、/drupal/rest_api/accesss_tokenを呼び出せばAccess Tokenが得られると外部ドキュメントに書かれていた。ついでに、このモジュールでAPI Key Authenticationを利用すれば、アプリがAPIキーを持っていれば認証を成功させることができる。さらに、Third Party Provider Authenticationを利用すれば、認証サーバーの分離も可能になりそうだ。
ユーザーコンテキストに結びついたAccess Tokenがセキュアに入手できれば、あとは特に心配な点はない。
これで自分的には謎は解けたのだが、せっかく認証、認可の理解を進めようと思ったのだからと別ケースを検討してみることにした。以前「エストニアの電話会社のポータルはDrupal9だった」というブログ記事で書いたが、Elizaは複数の認証サービスに対応しているものの自らは認証サービスを外部提供していない。ブログ記事のログイン画面は認可機能の実装でここで認可を受けるとユーザーページに飛ぶ。
冒頭のSmart-ID Technical Overviewの図で考えると、ブラウザはElisaのWebサイトであるRP（以下Elisa-RP）にアクセスし、リソースオーナー（私）はPersonal Codeを入力して認証サービスでOpenID connect準拠のSmart-IDを指定してElisaのWebサイトの認可を要求する。
Elisa-RPは、Smart-IDのAPIを呼び出している(Smart-ID-OP)。ここから先の認証にブラウザは関係なくて、ブラウザはElisa-RPからの返信待ちになる。つまり、認証の確認ができるならブラウザやアプリそのものには認証機能をもたせる必要はない。
Smart-ID-OPはpush messaging serviceを用いて、スマホのクライアントを立ち上げる。Smart-IDアプリは、デバイスとPersonal codeを登録する仕組みとなっていて、Smart-ID-OPがPersonal codeでpush messaging serviceを呼び出すと、Personal codeに結び付けられたデバイスに通知を送って、スマホのクライアントが立ち上がる。ここでPINを入れると認証が完了して、Elisa-RPはSmart-ID-OPの認証完了を受けてブラウザに認可を行う（セッションが確立する）。
ElisaのアカウントはPersonal codeと結びついているので、リソースへのアクセス制御はその情報に基づいて提供すれば良い。
ちなみにElisaのスマホアプリはMobile-IDというSIMに埋め込んだ公的証明書を利用した認証には対応しているが、Smart-IDには対応していない。Mobile-IDでElisa-RPが認証確認できればリソースアクセスを許すというのは合理的な判断と言えよう。
改めて分かったのは、認可サーバーは認証の確認をしないわけにはいかないが、認証の実施は認証サーバーの責任で認可サーバーの知ったことではない。Googleログインの場合は、ブラウザが既にGoogle認証を終えていれば、認証確認のためのリダイレクトを書けた時に認証画面がでないだけで、OpenID connectの手順でDrupalのcallbackが呼び出され、ID情報が得られているだけだ。ようやく、認証と認可の関係が腹落ちした。
※画像はsmart-id.comのSmart-ID Technical Overviewから引用させていただいたもの