Drupal9 美味しいレシピ集2に関わってから、Oauth2/OpenID connectにはまっている。
このサイトもそうだが、DrupalはSocial Authモジュールを使うことで、GoogleやFacebookをOP/IDPとして認証機能を移譲できる。Drupalはcoreでログイン機能を提供していて、認可機能を有している。内部的には、UIDという数値がIdentityとなるが、UIDには必ずemailアドレスが付随しており、同一サイト内では、異なるUIDに同じemailアドレスを対応させることができない。逆に言えば、emailアドレスがあれば、一意にUIDを特定できるかユーザーが存在しないことを確認できる。
Social Authでは、emailアドレスでIDPで認証して認証コード、アクセストークンを得れば、それからUIDを特定して、そのUIDでのセッションを確立させる。一度、セッションが確立されれば、OpenID connectでもDrupalの通常ログインでも差異はない。
実際に実験済みなのだが、同一のemailアドレスと結びついているFacebookアカウントとGoogleアカウントのどちらを使ってもセッションが確立すれば以降の挙動は変わらない。ログイン時は、/user/login/facebookあるいは/user/login/googleを選択でき、前者を選べばブラウザがfacebookログイン済みなら再びログインパスワード（や二要素認証）を求められることはないし、後者を選んでchromeがGoogleログイン済みでログイン済みのアカウントが一つであれば自動的にセッションが確立する。
Drupalの認可は、UIDに基づいて行われる。認可機能とリソースサーバー機能は不可分である。
Simple OAuth (OAuth2) & OpenID Connectモジュールを用いると、DrupalはOpenID connectのOPになることができる。つまり、認証が済んでいる段階でアクセストークンを発行することができ、アクセストークンを持っていれば、DrupalサイトのコンテンツにDrupalの認可ルールに基づいてアクセス(get/post)が可能になる。Social Authモジュールだけは、認可サーバーにはなれない。
Drupalが認可サーバーになるためには、常識的に考えるとアクセストークンからUIDを特定できる必要がある。また、アクセストークンを持っているクライアントがリソースオーナーの支配下にあることを検証しなければいけない。
現時点では、まだOauth2/OpenID connectにはまっているままなので、この部分がどうなっているのか理解が足りず、これ以上書けないのである。しかし、わかりたいと思っているので、この記事を上げておく。
ちなみにエストニアでは、emailアドレスではなく民間開放されているPersonal code(日本のマイナンバーに相当)を使うサイトが多い。IDカードに含まれる証明書を使えば政府が提供する認証サービスを使えるし、SmartIDのような認証サービスを認めれば、サイトは認可を判断できるようになる。