LINEの銀行サービスとは
Robert Mitchell氏（以下、Mitchell）：サーバーサイドチームのMitchell Robertと申します。本日、野田さんと一緒に、LINEの銀行サービスの開発について発表したいと思います。よろしくお願いします。
今日の内容ですが、以下の通りになります。まずはLINEの銀行サービスとはなにかついて、軽く説明したいと思います。その後、システムアーキテクチャと開発フローについて話したいと思います。最後は、認証と認可で、これは私たちが担当している部分です。これに関連するスペックや、セキュリティの仕組み、フローについて話したいと思います。
じゃあ、LINEの銀行サービスとは何かを簡単に言うと、新しいスマホ銀行です。みずほ銀行と手を組んで、LINE Bank設立準備株式会社を立ち上げました。現在、開業に向け準備を進めています。
LINEが世界中の人と人、人と情報、サービスとの距離を縮めてきたように、お金との距離を縮めていく。CLOSING THE DISTANCE。そして、スマホアプリで、どこでもバンキング。これは銀行の支店でできるようなことが、アプリでもできます。あとは、APIの提供も検討しています。これはOAS、OpenAPI Specificationの定義でドキュメンテーションを生成します。
実はもっとすごい機能も含まれる予定ですが、これ以上言ったら怒られそうなので、遠慮しておきます。
LINE銀行のシステムアーキテクト
次に、システムアーキテクチャに移りたいと思います。まず技術スタックなんですが、サーバーアプリ側は言語がJavaです。なぜかというと、安定していて、LINEで共通言語になっているためです。特にチームが多いため、これは重要な点です。そして標準のSpring Bootなどを使っています。
インフラの環境については、専用のデータセンターで提供する予定です。その他は、Data Storeの話なんですが、Redis, MySQL, Kafkaなどを全部使っています。
あとはソースコントロールとCI／CDの役割には、GitLab + Ansible Towerを使用しています。
LINE銀行の開発フロー
次は開発フローについてお話ししたいと思います。開発フローは、だいたいこのような流れになります。まず要件の仕様を読みます。もちろん、ミーティングなどで話し合う場合もあります。そしてOpenAPI Spec（OAS）でAPIを定義します。OASは、以前Swaggerと呼ばれていて、けっこう有名な技術なので、みなさんもご存じかと思います。
そして、その後YAMLでコード自動生成が行われます。このコードはJavaのインターフェイスになります。そして、このJavaコードの中にルートやURLも含まれているで、コードがスペックからズレることはほぼありません。
そしてCI／CDで、自動的にJavaにパッケージして、そのJavaファイルをGitLabのパッケージレジストリに載せます。このコード自動生成が終わったら、私たちのサーバー開発チームが、そのインターフェイスを実装します。実装が終わったら、マージリクエストを送ってコードレビューを行います。これが終わるまで繰り返します。
こういうフローを単純なアクティビティ・ダイアグラムにすると、このようになります。とりあえず要件が入ってきて、こういう要件を検討してからAPIをYAMLで定義します。
GitLabのOpenAPIビューワーでYAMLをHTMLに変換します。これはSwaggerUIを用いていますが、こういう定義が終わったら、コードを自動生成します。これをYAMLの修正をプッシュすると、GitLab CI／CDで自動的に動きます。
この自動生成が終わったら、実装の段階に入ります。実装が終わったら、コードビューを行います。もちろんこれで終わる時もありますが、もし開発の誤解があったり、もしくは修正が必要な場合は、左のほうに戻っていって、もしAPIの定義が必要だったらこのGitLabの定義の段階に戻って直して、コード自動生成を行なって、実装、コードビューとなります。こういう順番を終わるまでにくるくる回っていくみたいな感じになります。実は開発フェーズが終わったことはなかなかないんですけど。
はい。で、これは本番の例ですが、この左上のAPIをYAMLで定義して、この定義から右のドキュメンテーションと真下にあるJavaのコード生成できます。
次に、先ほど言ったフローをエクスポートするためのツールをリストアップしました。まず、OS用のエディターはStoplight Studioか、VS Code plus Open API Pluginのどちらかを使っています。
そしてドキュメンテーションの生成はSwagger UIを使っていますが、これはGitLabで自動的に動くので、全部やってくれるんです。
あとはコードの自動生成。これはOpenAPI generatorを使っていて、Javaだけではなく多数の言語対応しているので、けっこう便利なツールです。
そしてソースコントロールとCI/CDは、先ほども言ったとおり、GitLabになります。みなさんぜひお試しください。本当に便利なツールなのでおすすめです。
次は認証と認可になりますが、野田さん、引き継ぎをよろしくお願いします。
LINEの銀行サービスの認証
野田誠人氏（以下、野田）：はい、では認証と認可について説明いたします。とは言っても、残念ながらまだLINEの銀行サービスはリリースされているわけではないので、具体的にどう実装をしているかはちょっと現在まだお話できません。
ということで、認証と認可に関する技術的なお話を紹介しようと思っています。
まず認証ですが、中でも一番有名なのはOpenID Connectだと思います。順番が前後しますすが、後に出てくる認可のOAuth2.0のフローに載せてこれはJWTと呼ばれるIDトークンを発行して、この人はどういう認証方法で私たちのプラットフォームが認証した正式なユーザーです、というのを証明するトークンを発行する技術です。
だいぶメジャーになってきていると思います。いろいろなところで見られます。LINEなら、LINEログインはOpenIDのConnectのIDトークン発行しているので、もし興味があれば、そちらの資料もデベロッパーズ向けに資料公開されていますので、ご覧ください。
次のFIDO2は、最近いろいろな銀行アプリで採用されてきていてる、生体認証などを使うというものです。その中のWebAuthnは、Mozillaなどのブラウザーに搭載されている機能で、ブラウザーなどいろいろ構成されている技術として公開されています。
FIDO2には、「FIDOアライアンス」という団体があって、LINEもサービス事業会社として世界初の「FIDO ユニバーサルサーバー」の認証を取得しています。先日、OSS として公開されました。LINEの場合は、現在LINEで生体認証を使ったリモートログインが実装されています。
ちょっとこれは未来の話ですが、DIDというのもあって、これについてサラッとお話しします。これは特定のベンダーに認証情報を集めるんじゃなくて、各々のデバイスなどに自分のIDを持たせて、それで起動しようという技術です。
まだ議論の途中で、実現するのはだいぶ先の話になりそうですが、おもしろいので、興味があればぜひ追ってみてください。
LINEの銀行サービスの認可
次に、認可についてお話しします。認可と認証というのは、似ているようで違うということが、だいぶ昔から言われてきていますが、銀行のシステムでも、これらをしっかり区別してやろうとしています。
現在の定番はOAuth2.0が有名ですが、このように「RFC6749」といったいろいろなベースがあって、時代の流れに乗って、これはセキュリティ的にちょっと危険なのでドロップしようとか、こういう機能を追加しようといったようなものが、どんどんどんどんRFC化されて追加されています。
それをまとめようとして再編集されたのが、まだドラフトのOAuth2.1です。今後はこちらが主流になってくると思います。その上にOpenID Connectが載って、さらにFAPIというものがありまして。
FinancialGradeAPI（ Part 1: Baseline / Part 2: Advanced ）、これもOpenID Connectの団体から出ているんですが、まさに銀行や金融サービスのためのOpenID Connectのプロファイルです。
プロファイルといっても、何か新しいものはありません。すでに出された技術に対して、このセキュリティを高めるためにこれをしてくださいといったチェックリストのようなものが定義されているものです。それを図にしたものがこんな感じです。
現在、これらの技術は、ほとんどドラフトのものが多いです。私たちは、最新のセキュリティである、こういった事柄を、勉強しながらできる限り取り入れていって、システムを作り上げようと、開発しているところです。
その中で、セキュリティの仕組みとして、「認可フロー」「クライアントの認証」「トークンバインディング」「認可コードの保護」のところを、ちょっと上げてみます。
それと他に「CIBA」と呼ばれる認可フローもあって、こちらは、後で出てきますが、要は手元のデバイスで認証するということです。ブラウザの中でポチポチッとボタンを押して、そしたら手元のスマートフォンに「これ本当にあなたがやったものですか」っていうのが出て、はい・いいえと認証するようなものを正式にスペック化、仕様化したものが「CIBA」です。
新しいものだけでなく古くからある技術がうまく利用されることもあります。例えば、RFC 8705は、昔からあるクライアント認証で互いのクライアント証明書を認証時に確認する mTLS という仕組みを、OAuth におけるクライアントの認証やトークンの所持証明に利用しようというものです。
Private Key JWTは、秘密鍵、公開鍵を作成して、公開鍵を登録しておいて、秘密鍵で生成したJWTを検証することによって、正規のクライアントと認証するクライアント認証の技術です。
OAuthのクライアント認証は、昔からクライアントIDとシークレットキーとなっていたのですが、最近はもうシークレットを使わないもののほうがセキュリティが高いということで、これからそちらが主流になってくると思います。
現在のOAuth2.0では、トークンを知っていれば誰でもリソースにアクセスできたのですが、このトークンの正常な持ち主がアクセスしているかどうかまでちゃんと確認しようというのが、トークンバインディングです。
それにはDPoPや、先ほども出てきたmTLSを使ってトークンを事前に発行する時に「この情報を持った人じゃないと使ってはダメですよ」って登録するようなものです。
銀行などの場合は、トークンを盗まれてアクセスさせるわけにはいかないので、認証と紐づいて、こういうトークンバインディングの機能も検討しています。
これが先ほど紹介した「CIBA」ですね。通常のOAuthというのは、フロントチャネルといいますか、ブラウザ上で動くのが前提となっていたんですが、もう最近はブラウザ上ではなくてサーバー上の通信で、非同期に認証していこうというのが主流になると思っています。
よりよい銀行システムをお届けできるように
ちょっといろいろ文字ばっかりで説明しましたが、私たちはこういった技術を日頃取り入れて、よりよい銀行システムをみなさんにお送りできるようにと開発しています。興味がある方は、ぜひ一緒に開発してくれたらと思います。
以上で、銀行事業の開発チームからの紹介を終わります。
