OAuth:認証させずにリソースを提供する安全な仕組み
はい、こんにちは。前回記事の続きです。ユーザに代わって、アプリが別サービスのAPIを利用できるようにする枠組み「OAuth」についてご紹介しています!
前回は、まず全体像を把握したい!ということで、簡略なOAuthの流れをご紹介しました。OAuthクライアントがリソースへのアクセス許可(認可)をしてもらうのでしたね!
「OAuthで何を実現できるのか」がつかめたところで、今回からOAuthの詳細を掘り下げていきましょう!今回は、「そもそもOAuthってどうしてありがたいの?」という疑問を解決します。
ではいきましょう!
OAuthって何の略?
まずそもそもOAuth(オウオース)って何の略でしょうか?少し想像してみてください。Authは、「Authothentication」(認証)だろうって思いますよね。
でも違うのです。実は、「OAuth」は、「Open Authorization」、「オープンな認可」です。スペルも発音も似ているので、英語のネイティブにとっとも紛らわしいらしいですよ。
「認証」は、ある人が本当にその人であることを確認することです。一方、「認可」は、その人にアクセス権を与えることです。
おさらいになりますが、これはきちんと区別しておきましょう。
「認証」させるのはリスク大
ここで疑問が浮かびます。『Aサービス(クライアント側)が、Bサービス(リソース側)に「認証」してもらってから、「認可」してもらうのが普通では?』
ええ、確かに。まずログインしてから、定められたリソースにアクセスする…。それがよくある流れですよね。
しかし、これはセキュリティ的によろしくないのです。AサービスがBサービスに認証してもらうためには、Bサービスのパスワードを持つ必要があります。
Bサービスにとって自分のサービスのパスワードを別のサービスに渡すのはリスクが大きすぎます。例えば、Aサービスがパスワードを漏洩させるかもしれません。さらに、ログインしたあげく、Aサービスに悪さをするかもしれません。
これはいただかけない。
OAuthで最小限の権限を渡す
そこでOAuthの仕組みの登場です。OAuthでは、ユーザはAサービスにしかログイン(認証)しません。その上で、Aサービスは、Bサービスにアクセス許可(認可)だけしてもらいます。
これにより、Bサービスは、Aサービスにパスワードや、不必要で過剰な権限を渡さずに、APIを利用してもらえるわけです。
このように、OAuthは、セキュリティを高めつつ、便利にAPIを利用できる仕組みなのです。
APIの必要性
すみません。API(Application Programming Interface)ということばを解説なしで使っていました。念のため、補足させてください。
言葉どおりとすれば、「アプリをプログラミング(開発する)ときに必要になる窓口」ということです。なんのこっちゃい。
こんにち、アプリを利用するときに、データをユーザの端末内で全部保管することは現実的ではありません。そうならば、クラウドにあるデータをアプリが利用できるようになればいいのです。そのクラウド側の窓口が「API」というわけです。
このAPIが公開されているおかげで、アプリを製作する側は、他種多様なサービスを短期間で作れます。開発者もユーザもうれしいですね。
しかし、便利さとリスクは表裏一体です。リソースを外から提供してもらえるようになることで、そこを攻撃されることがあるのです。
これに対する対策の一つが、認証を行わない「OAuth」なんですね~。
はい、本日はここまで。今回は、OAuthとは何がうれしいのかについてお話ししました。最小の権限をクライアント側に渡すのでした。
次回は、OAuth2.0の仕組みをお話ししましょう!
では!