Interview

Authlete はAPIエコノミーの基盤となる認証・認可技術をクラウドサービスで提供し成長を目指す

Authlete Japan 川崎 貴彦 × Longine FinTech取材班

今回は、株式会社Authlete Japanの川崎 貴彦代表取締役に、Web APIの認証及び認可の機能を実装するクラウドサービスへの取り組みについて伺いました。

読者に伝えたい3つのポイント

Authlete Japanは認証・認可技術をクラウドサービスで開発会社等に提供することを目的に2015年9月に創業されました。

同社のソリューションは、認証と認可を分離したアーキテクチャーに特色があり、これによりユーザーは既存のシステム資産を活かしながら迅速かつ効率的にWeb APIへの対応を進めることができます。

APIエコノミーは分野を問わず拡大しているため、同社は金融(フィンテック)に留まらず、IoT、EC、ヘルスケアなど様々な市場を事業機会として取り込むことが期待できます。

認可(Authorization)と認証(Authentication)技術をクラウドサービスで提供

Longine FinTech取材班(以下、Longine):社名は会社が目指す姿を現すと言われますが、なぜAuthleteという社名にされたのでしょうか。

Authlete Japan 川崎貴彦 代表取締役(以下、川崎):弊社は2015年9月にAPIエコノミーの基盤である認可(Authorization)と認証(Authentication)を行う機能の実装をクラウドで提供することを目指して設立されました。

社名については、弊社のキーワードであるAuthorization、AuthenticationがいずれもAuthから始まっているので事業をイメージしやすいと考えたのが第一です。また、leteには動詞としての語感があるので、たとえば「Google it(ググる)」のように、将来は認可サーバーをAuthleteを使って実装することを「Authlete it」と言われるような会社になりたいと考えています。加えて、アスリートに綴りが似ていること、アルファベット順で早いほうが目立つ、辞書にない造語のほうが検索をした時にそれしか出てこないことなども考慮しました。

Longine:御社は、どういった顧客を対象にしているのですか。

川崎:弊社の直接の顧客はシステム開発会社(デベロッパー)やサービス提供会社です。一般消費者の目にはあまり触れない黒子的な役割を担っており、ビジネスの形態はB2BあるいはB2Dです。ここでのDはデベロッパーのことで、デベロッパーが使うツールをBaaS (Backend as a Service)として提供しています。

Longine:価値をBaaSで提供するB2Dビジネス型のビジネスモデルということですね。

川崎:そうです。海外では、このビジネスモデルは非常に堅実な成長が見込めるということで注目を集めています。たとえば、オンライン決済サービスの提供を行うスタートアップで急成長している「Stripe」が一例です。同社は、決済の仕組みをWeb API で提供しており、Webサイトに決済機能を入れたいとする顧客は、そのAPIをはめ込むだけでできてしまうのです。システムデベロッパーが必要とする機能を、コンポーネント化してBaaS として提供することでの成功している典型例だと思います。

認可と認証に着目した理由

Longine:では、なぜ認可(Authorization)と認証(Authentication)の部分に着目されたのでしょうか。

川崎: 数年前、あるサービスをWeb APIとして提供するビジネスアイディアを思いつきました。そのWeb APIの利用に対する認可処理を行うため、OAuth 2.0の仕様に基づく認可サーバーを実装する必要があり、オープンソースソフトウェアを探しました。しかし、満足のいく実装を見つけられませんでした。

そこでOAuth 2.0ライブラリの自作を始めたのですが、ほどなくして、入力パラメーター解析や出力データ整形の部品を用意したところで、とても薄いライブラリにしかならないことに気が付きました。むしろ大変なのは、そういう部品をどのように組み合わせて利用するか、データをどのように保存して維持管理していくか、という点だったのです。認可サーバー実装者側の視点に立ち、その大変な部分をやってくれる仕組みはどうあるべきかを考えていったところ、ライブラリ形式ではなく、裏にデータベースを持つBaaS形式であるべきだ、という結論に至りました。

しかし、BaaS形式にはサーバー運用費がかかるという問題があります。ただ、そこで、「運用が必要なのであればビジネスになる」ということに気が付きました。つまり、認可に特化したBaaSというビジネスアイディアを思いついたわけです。元々考えていたビジネスアイディアよりも有望に思えたので、そちらに舵を切ることにしました。

既存の個人会社の一事業として行う選択肢もありましたが、知人に相談したところ、「その事業内容ならばシリコンバレーでは一つ会社ができる」と言われたので、この事業のためにAuthlete社を設立することにしました。

Longine:OAuth 2.0というあまり耳慣れない言葉が出てきました。簡単に解説していただけないでしょうか。

川崎:OAuth 2.0は、クライアントアプリケーションが認可サーバーからアクセストークンを取得する手順の標準規格のことです。RFC 6749(Request For Comments:IETFによって管理されているインターネットに関するさまざまな事柄を規定した仕様書群のこと)として詳細な仕様が規定されています。

具体的には、異なるサービスの連携において、外部からのデータやサービスに対するアクセスを利用者の同意に基づいて認可するための仕様です。OAuth 2.0を使えば、たとえば家計簿ソフトに銀行の残高データを取り込むことが、自分の銀行のIDやパスワードを家計簿ソフトの運用会社に漏らすことなく、必要最低限のアクセス権限のみを委譲することで可能になるのです。

具体例で説明しましょう。

家計簿アプリ(以下、A)と、そのユーザー(以下Bさん)との関係は、Aから見たらBさんはエンドユーザーです。そして、Bさんは銀行(以下、C銀行)に口座を持っています。

まず、OAuth 2.0が実装されていない場合ですと、AはC銀行にログインするために、BさんからIDとパスワードを預かります。Aはそれを使い仮想的にログインします。C銀行から見たら、アクセスしたのがAなのかBさんなのか分かりませんが、C銀行はBさんだと考え応答し、残高情報を読み取るのです。

このような仕組みでは、AはBさんのIDとパスワードを持っているので悪いことをしようと思えば何でもできてしまいます。つまり、BさんがAを信頼している場合にのみ成り立つ仕組みです。

これに対して、第三者であるAにIDとパスワードを渡さずにアクセス許可を与える仕組みがOAuth 2.0なのです。その場合のフローは次のようになります。

BさんがAのサイトに行くと、C銀行との連携ボタンが現れます。そのボタンを押すと、C銀行のサイトに繋がり、“Aアプリが残高照会権限を求めています”、と表示されます。「認めますか?」というダイアログでそれを認めるとIDとパスワードを表示する画面が出てきます。それをC銀行の方でチェックしてBさんは認証され、そのことを認める「アクセストークン
とよばれる“アクセス許可証”が発行され、Aに渡されます。

この時Aが受け取るのは、Bさんの銀行用のIDとパスワードではなく、その代わりのアクセストークンですが、これによってC銀行のサイトで“残高照会のためのWeb API”にアクセスできるようになるのです。

このように、認証は銀行が行い、そこで発行されたアクセストークンで銀行のAPIへのアクセスが可能になるというフローがOAuth 2.0によって成り立つことになります。

株式会社Authlete Japan 川崎貴彦 代表取締役

拡大が期待される対象市場とAuthleteの強み

Longine:この仕組みが使えるのは「銀行API」だけに限らないですよね。

川崎:その通りです。銀行は、残高照会など色々なAPIを今後も作っていくと思いますが、同様な動きはフィンテック分野に限らず、ヘルスケア、オンラインマーケット、IoT分野などでも起こっています。このため、あらゆる業界のWeb APIが対象になり得ます。

どのようなWeb APIであれ、最初にやることはアクセストークンのチェックです。そのためには、アクセストークンを発行する仕組みが必要となります。この仕組みのことを「認可サーバー」とよんでいますが、一から作りあげることは結構大変で、大手のサービス企業でも実装に失敗しているケースが見られます。非常に専門性が求められる作業なのですが、この分野に強いエンジニアが育っていないというのが実情です。

このため、弊社のように認可サーバーをWeb APIとしてクラウドサービスで提供する会社は、これから大きく伸びるチャンスがあると考えています。

Longine:同じようなサービスを提供する会社が増えてくる可能性もあると思いますが、御社の競争優位性はどこにありますか。

川崎:端的に申し上げれば、製品アーキテクチャーが優れていることです。弊社のソリューションは、認証(誰であるか)と認可(誰が誰に何の権限を与えるのか)を分けて開発することを前提としたアーキテクチャーとなっていることが最大の特色です。また、認可の部分に特化していることも他社にはない特色です。

Longine:認証と認可は密接な関係があると思いますが、それを分離することのメリットはどのようなものでしょうか。

川崎:認証技術には、指紋認証、光彩認証、二要素認証、ハードウエアトークン、乱数表、ワンタイムパスワードなど様々な種類があり、年々高度化しています。一方、弊社のソリューションは、先ほど申し上げたように認証と認可を分離してシステムを開発することが前提となっていますので、どのような認証技術とも組み合わせが可能であり、また、既存の認証の仕組みをそのまま活用することもできるのです。

銀行の場合ですと、オンラインバンキングシステムで認証の仕組みを長年にわたって利用していますが、新たにWeb APIを導入する時にも、その既存の認証の仕組みを活用できますし、認証部分については最先端のものに容易にアップグレードすることが可能となります。

このため、銀行に限らず多くの業界の方から、既存のサービスにWeb APIを追加するときに、「認証と認可の分離」という弊社の設計アーキテクチャーが「とても刺さった」というフィードバックを、これまで多数いただいてきました。

Longine:認証と認可の分離以外に、差別化ポイントはありますか。

川崎:ユーザー情報データベースを認可システムと共有する必要がないことも弊社の特色です。一般的には、認可処理の一部に認証処理が含まれるため、認証と認可を分離することは難しいのですが、弊社独自のアーキテクチャーにより、認可に特化したソリューションとなっています。このため、顧客は認可システム用のデータベースを維持管理する必要がないのです。

Longine:金融以外で今後、採用が広がりそうな市場はありますか。

川崎:IoT分野です。シリコンバレーでは、「認可」や「認証」を取り込んだIoT技術で製品サポートを行おうとする取り組みが始まっています。販売したハードウエアをリモートでサポートするために、そのハードを「認可」や「認証」する仕組みです。

弊社は認可サーバーを作るためのWeb APIを公開していますが、実はアクセストークンを発行するプロセスを手作業で行う方法も作っています。この技術を活用していけば、現状のやり方よりも効率的、かつ正確に製品サポートができるようになる可能性があります。

APIエコノミーとともに成長を目指す

Longine:今後どのようにビジネスをスケールさせていくのですか。

川崎:弊社のビジネスは、冒頭にお話ししたようにB2D市場を対象としており、弊社が提供するサーバーを使ってもらい使用量に応じて月額課金を行うビジネスモデルです。ただし、最初に顧客のサービスに組み込む時には、ある程度の技術力が必要となるため、SIerのサポートが必要となります。特に、日本では最終顧客(銀行業、SNSサービス、ECなどを行う企業)はSIerにシステム開発を依頼するケースが非常に多いため、弊社のパートナーとなっていただけるSIerとの関係構築に現在注力しています。

一方、海外では、最終顧客は自社に優秀なエンジニアを抱えているケースが非常に多いため、評判が高まれば自然と顧客は広がっていくと考えています。

Longine:最後に長期的なビジョンを教えて下さい。

川崎:ネットの世界では、様々なサービスがWeb APIで繋がることで、経済成長に大きなインパクトを与えています。ECの世界ではモバイルからのアクセスが急激に高まりましたが、これもモバイルアプリがECサイトの提供するWeb APIに繋がっているのです。また、SNSの世界でも、モバイルゲームやECのアプリとWeb APIを介して連携することでユーザーが増えています。

つまり、Web APIを公開することによって、より多くの人にリーチできるようになるのです。こうした観点から、弊社はAPIエコノミーの基盤技術を提供することをミッションとしています。このため、フィンテックよりもさらに大きいAPIエコノミーにおいて、グローバルレベルでの長期的な成長を目指したいと考えています。

Longine:本日はお忙しいところありがとうございました。

川崎:こちらこそありがとうございました。