OAuth：認証させずにリソースを提供する安全な仕組み

はい、こんにちは。前回記事の続きです。ユーザに代わって、アプリが別サービスのAPIを利用できるようにする枠組み「OAuth」についてご紹介しています！

前回は、まず全体像を把握したい！ということで、簡略なOAuthの流れをご紹介しました。OAuthクライアントがリソースへのアクセス許可（認可）をしてもらうのでしたね！

簡略化したOAuthの流れ

「OAuthで何を実現できるのか」がつかめたところで、今回からOAuthの詳細を掘り下げていきましょう！今回は、「そもそもOAuthってどうしてありがたいの？」という疑問を解決します。

ではいきましょう！

OAuthって何の略？

まずそもそもOAuth（オウオース）って何の略でしょうか？少し想像してみてください。Authは、「Authothentication」（認証）だろうって思いますよね。

でも違うのです。実は、「OAuth」は、「Open Authorization」、「オープンな認可」です。スペルも発音も似ているので、英語のネイティブにとっとも紛らわしいらしいですよ。

「認証」は、ある人が本当にその人であることを確認することです。一方、「認可」は、その人にアクセス権を与えることです。

おさらいになりますが、これはきちんと区別しておきましょう。

「認証」させるのはリスク大

ここで疑問が浮かびます。『Aサービス（クライアント側）が、Bサービス（リソース側）に「認証」してもらってから、「認可」してもらうのが普通では？』

ええ、確かに。まずログインしてから、定められたリソースにアクセスする…。それがよくある流れですよね。

しかし、これはセキュリティ的によろしくないのです。ＡサービスがＢサービスに認証してもらうためには、Ｂサービスのパスワードを持つ必要があります。

Ｂサービスにとって自分のサービスのパスワードを別のサービスに渡すのはリスクが大きすぎます。例えば、Ａサービスがパスワードを漏洩させるかもしれません。さらに、ログインしたあげく、Ａサービスに悪さをするかもしれません。

これはいただかけない。

OAuthで最小限の権限を渡す

そこでOAuthの仕組みの登場です。OAuthでは、ユーザはAサービスにしかログイン（認証）しません。その上で、Aサービスは、Bサービスにアクセス許可（認可）だけしてもらいます。

これにより、Bサービスは、Aサービスにパスワードや、不必要で過剰な権限を渡さずに、APIを利用してもらえるわけです。

このように、OAuthは、セキュリティを高めつつ、便利にAPIを利用できる仕組みなのです。

APIの必要性

すみません。API（Application Programming Interface）ということばを解説なしで使っていました。念のため、補足させてください。

言葉どおりとすれば、「アプリをプログラミング（開発する）ときに必要になる窓口」ということです。なんのこっちゃい。

こんにち、アプリを利用するときに、データをユーザの端末内で全部保管することは現実的ではありません。そうならば、クラウドにあるデータをアプリが利用できるようになればいいのです。そのクラウド側の窓口が「API」というわけです。

このＡＰＩが公開されているおかげで、アプリを製作する側は、他種多様なサービスを短期間で作れます。開発者もユーザもうれしいですね。

しかし、便利さとリスクは表裏一体です。リソースを外から提供してもらえるようになることで、そこを攻撃されることがあるのです。

これに対する対策の一つが、認証を行わない「OAuth」なんですね～。

はい、本日はここまで。今回は、OAuthとは何がうれしいのかについてお話ししました。最小の権限をクライアント側に渡すのでした。

次回は、OAuth2.0の仕組みをお話ししましょう！

では！