4月にもLSATに関する記事を書きましたが、最近また話題に上がっているので、前回の記事で「もっとMacaroonに詳しくなりたい…」と締めていたように、理解しきれていなかった部分について勉強してきましたのでアップデートさせていただきます。

LSATとは(復習)

支払いをしなければアクセスできないよという意味のHTTPステータスコード402 Payment Requiredに対してLN支払いを行い、得られるLSATというトークン(支払いのプレイメージを含むMacaroon)を提示するという流れを規格化することで有料リソースをシームレスに購入・アクセスすることができるようにする、Lightning Labsが提唱したコンセプトです。

背景等について、詳しくは4月の記事をご覧ください。

MACAROONとは

皆さんはウェブを閲覧していてCookieという用語を目にしたことがあるでしょうか。Cookieというのは、サーバー側に保存されるウェブサイトのセッション情報(例えばショッピングカードに追加した商品のリスト)とブラウザを対応させるためのトークンです。ブラウザに保存されます。

Macaroonもサーバー側が発行するログイン・権限管理用のトークンなのですが、トークン自体に権限が記載されていることが特徴です。サーバー側の秘密鍵で署名されているため、発行されたMacaroonの権限を勝手に書き換えることはできません。あくまでアクセス時にMacaroonを提示し、そこに記載されている権限の範囲内での利用が可能となるトークンです。

原理的には、発行元が「秘密鍵＋権限の制約情報」をハッシュしたものがMacaroonだと思って下さい。フォーマットは規定されていないので、各発行元によって異なります。

Macaroonの特徴として、「権限委譲できる」ということがあります。権限委譲とは、他社の認証などを権限の条件に追加することができるということです。例えば自社サービスの利用に「ツイッターへのログインを必須とする」という条件(権限委譲)を加える場合、ユーザーはツイッターにログインしてMacaroonを受け取り、利用するサービスのMacaroonと組み合わせてサービス側で検証することになります。

また、Macaroonは他のユーザーに新たな制限を加えて渡すことができます。こちらは、原理的には「前のMacaroonの署名＋新たな権限の制約情報」をハッシュして渡すのですが、例えば自分の他のデバイスで一定期間使えるMacaroonを発行したり、一部機能のみが使えるものを友人に渡すことができます。

どういう意味か、実際の例で見てみましょう。

例えば、動画投稿サイト「V」が、ストレージを提供してくれるAWSからMacaroonを受け取ります。(「V」のデータ保存・配信権限はAWSのMacaroonによって規定されている)
「V」は動画を閲覧する際、ユーザーがツイッターにログインしていることを必須にしたいので、ツイッターにシークレットを共有してもらい、ユーザーに発行したMacaroon内でツイッターからもMacaroonをもらってこいと指示します。(ユーザーによるAWS上の「V」動画閲覧の権限はツイッターへのログインに少なくとも一部が委譲されている)
ユーザーはツイッターからもらってきたMacaroonと「V」から受け取ったMacaroonを組み合わせて「V」に送信し、「V」はそれを検証してAWSに渡し、問題がなければAWSはユーザーに動画を配信します。

Macaroon自体に権限が記録されているので、発行時に設定するだけで以後は受け取った際にMacaroonが不正でなければ規定されている通りの行動を許可するだけでよく、ユーザー管理をしないでいいので楽です。

LSATへの批判

まず、Macaroonを利用する流れ自体がけっこう複雑な上に、元々MacaroonはGoogleが社内利用用に開発したものであまり広く利用されておらず、情報が少ないです。オープンソースですが、GitHubにあるMacaroonjsなどいくつかの実装と、いくつかの記事・動画以外、あまり情報がないので理解が難しいです。日本語情報などほぼ皆無です。Lightning Labs CTO @roasbeefの趣味なのではという批判さえもあります(笑)

また、Lightning LabsはかなりアグレッシブにLNDに新機能を追加していて、あまりのペースに若干白い目で見られているところがあります。

LSATが優れているところ

LSATの画期的なところはMacaroonを使っているところであり、Macaroonをあえて利用する理由としては「権限委譲」があります。

これは例えば現在OAuthなどで行っている第三者サービスでのログインや、公的な身分証明機関が発行するMacaroonがあればKYCなどに利用することができます。ブロックチェーンを使うわけではないし非中央集権的でもないけど、ブロックチェーンIDと発想は似ているかもしれません。

また、後述するJSONWebTokenやAPIキーと同様にリクエストごとに提示するので、ログイン状態の管理も不要です。

LNURL-AUTHが優れているところ

LNURL-authは、HDウォレットと同様の仕組みでサイトごとに鍵を用意することで、各サイトにおいて公開鍵暗号方式でのログインを可能にする規格です。QRコードをウォレットに読み込むだけでログインできるシンプルさ、勝手にサービスごとに違うIDで登録できるプライバシーが売りとも言えます。fiatjafのブログに、似た発想であるWebauthnやBitIDの欠陥を改善したものである、との説明があります。

要するに、LNURL-authは既存のログイン手段(メール＋パスワード、SNS連携など)を置き換える性質のもので、ログイン状態の維持にはセッションとCookie、またはJSONWebTokenなどの利用が必要です。

JSONWEBTOKENでいい場合

JSONWebToken (JWT)とは、サーバーが発行し、「データ＋サーバーによる署名」という形式を持つトークンです。多くのアプリがCookieの代わりに使っているため、Macaroonよりドキュメントが充実していて、今すぐ使い始めやすいトークンベースのログイン管理です。

LSATの代替としては、権限委譲の仕組みなどはありませんが、第三者サービスでのログインやKYCが不要な場合、JWTをLightning払いの対価として発行することでアカウント不要のサービス開発ができると考えられます。JWTの効果が切れた場合(期間終了、回数超過など)にLNインボイスを返せば良いです。(このプロセスも規格化されたほうが良いとは思います。)

JSONWebToken以外にも、APIキーなどのようにサーバー側でアクセス権限の管理をする仕組みはいろいろあります。JWTには、それ自体に情報を記載できるので、送られてきたトークンを見るだけでよく、データベースなどで権限を照会する必要がない点に少しメリットがあります。

結論

様々な仕組みを比較すると、
・LSATは権限委譲が必要なユースケース(現時点では使い物にならないが、将来的には第三者サービスでのログインやKYCなどが想定される)でトークンにログインや権限の管理をさせる
・LNURL-authは現在主流のログイン手段に置き換わるもので、権限やログイン状態の管理は従来どおり
・JSONWebTokenは権限委譲が必要ない場合にトークンにログインや権限の管理をさせる
・APIキーはトークンだが権限の管理はサーバーが行う
という形になります。

前回の記事でもLSATがデファクトスタンダードになれるかは別問題としましたが、Macaroonの難しさや利用の少なさによって権限委譲というメリットすらも殺されており(委譲先のサービスが存在しない)、しばらくはLNURL-authやJSONWebTokenベースのソリューションのほうが主流になりそうという感じでしょうか。

まだまだ実装しているケースが少ない分野ですが、特に簡単なサービスやAPI等に関してアカウント不要の仕組みはサービス側も利用者側も楽なので今後広まっていくと思います。