理由は以下の2つの欠点があるためだ。なりすまし問題1つ目に、トークンが一度誰かに知られるとなりすましが簡単に行えるという点。このトークンはそのユーザーが自分であることを示す唯一の方法であり、これが誰かに知られると簡単になりすましが可能となる。この問題に対応するためにもし問題が起きた時にすぐトークンを再発行できるような仕組みにしたり、2週間で強制的にトークンの有効期限を切らせて再度ログインさせる、などの処置が行われているサービスがある。どちらの対応も不完全であることは言うまでもない。passwordの入力が必要2つ目に、クライアント側でemailやpasswordなどそのサービスの個人情報を入力しなければならない点にある。外部の組織が作ったアプリで、自社のサービスのemailやpasswordを入力させてしまうと、いとも簡単に個人情報を盗むことができる。これこそがパスワード認証における最大の問題である。いうことで次の方法である、事前にトークンを発行するやり方がある。トークン認証トークン認証はあらかじめ自社サービス内でトークンを発行してしまい、そのトークンだけを外部サービス連携時に使う、という方法である。有名なAPIでもよく使われている方法である。この方法ならまず前述の問題は解決できるが、ユーザーはログインの代わりにその長いトークンを別で入力する手間ができる。いう場合に効果的である。外部システムが自社サービスの特定ユーザーのみの情報を扱いたいだけ、という場合に利用できる。作るにはどうしたらよいのか。ここで認証コードの発行が登場する。ログインを自社の画面でやらせて、ログインに成功したら認証コードを発行するのである。複雑になってしまったが、よくあるTwitterの連携画面を思い浮かべていただきたい。Twitterと連携するアプリを作る時、連携元サービス(クライアント)の"Twitterログイン"ボタンを押すと、ログインはTwitter内で行われ、許可を押すと連携元サービスに飛ばされる。実現することが可能になる。すると外部の開発者が、Twitterアプリや、Facebookアプリなどのような"アプリ"が作れるようになる。最後に残るのはこのトークン問題だ。トークンがいつまでも同じだと取られたら終わり、という問題に対応する方法がこの記事の最後になる。今まで呼んでいた"トークン"は、基本的に変わらないトークンである想定だった。これを柔軟に定期的に変えられるようにすればセキュリティの問題もクリアできる。アクセストークンは、有効期限の短いユーザーを識別するためのトークンである。リフレッシュトークンはアクセストークンよりも有効期限が長く、アクセストークンを更新するために使うトークンである。アクセストークン・リフレッシュトークンを返却するAPIが多い。呼ばれている仕組みであるためだ。OAuthのより詳細は別の書籍などを参照していただきたい。以下のイメージである。アクセストークンとリフレッシュトークンを取得できたら、基本的にはアクセストークンでAPIとやりとりする。アクセストークンはできる限り短い有効期限で、しばらくすると期限切れになる。したらリフレッシュトークンを送って再度アクセストークンを再取得し、そのアクセストークンでまたAPIとやりとりするようにする。これによりトークンにおける問題を解決することができた。終わりにAPIの認証は実装上最大のハードルと言ってもいい。これさえ上手く構築できればAPIの大部分の問題をクリアできたと言える。認証の方法は、想定するAPIの使われ方次第で実装が大きく変わる。上記のメリット・デメリットを理解した上で最適なAPIを設計していただきたい。使っていれば、心強いサードパーティGemがあるから安心していただきたい。次はその他のAPIの課題について考え、その後にRailsにおける認証を考えていきたい。