プログラミング学習

OAuth入門【概要編】

OAuthを使ったサービス開発はしたことありますが、認可サーバーの実装はしたことなく、一度きちんと勉強することにしました。

勉強した内容をブログにまとめていきたいと思います。

ヨノ
認証・認可ってエンジニアとして必須科目的な印象があるので、ちゃんとやらなきゃな〜とは思っていたんですよね。

初回は概要編。

認証と認可とは?

よりよくわかる認証と認可」がとってもわかりやすい。

参考リンクを見てほしいですが、ざっくり要約すると

  • 認証
    通信の相手が誰であるかを確認すること
  • 認可
    とある特定の条件に対して、リソースアクセスの権限を与えること。ここでは相手が「誰であるか」という考えはない。

「通信の相手が誰か」を確認するかどうかがポイント!

 

OAuth 2.0 登場人物

登場人物

  • リソース所有者(Resource Owner)
    • 保護されたリソースへのアクセスを許可するエンティティー。ほとんどの場合リソース所有者は人であり、エンドユーザーと呼ばれる。
    • 多くの場合、エンドユーザーはWebブラウザを使って認可サーバーとのやり取りをする
  • リソースサーバー (Resource Server)
  • クライアント(Client)
    • リソース所有者の許可を得て、リソース所有者の代わりにリソースサーバーに対するリクエストをするアプリケーション
    • 主な責務は認可サーバーからアクセストークンを取得し、リソースサーバーに対して使うこと。アクセストークンの中身を知るべきではなく、意味不明な文字列として扱う。
  • 認可サーバー(Authorization Server)
    • OAuthの仕組みの中心的な役割を担うHTTPサーバー
    • リソース所有者とクライアントの認証を行い、リソース所有者にクライアントを認可する仕組みを提供し、クライアントにアクセストークンを発行する
    • 認可サーバーとリソースサーバー間のやり取りについてはRFC6749の仕様書の範囲外。認可サーバーはリソースサーバーと同一のサーバーでも異なるサーバーでも良い。単一の認可サーバーが複数のリソースサーバーにアクセス可能なアクセストークンを発行しても良い。

 

OAuth 2.0 とは?

OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである. サードパーティーアプリケーションによるアクセス権の取得には, リソース所有者とHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが, サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある. 本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.

引用元:RFC6749

OAuth 2.0 は認可プロトコル(委譲プロトコルとも言える)であり、リソースを管理している誰か(リソース所有者)がアプリケーションにオーナー自身のなりすましをさせるのではなく、リソース所有者の代わりとして対象のリソースへのアクセスを許可するための手段

OAuth のプロトコルの目的は、アクセストークンをクライアントに取得させ、クライアントにアクセストークンを使わせてリソースサーバーにリソース所有者の代わりとしてアクセスさせること。

 

例えば、ユーザーの代わりにツイートしたり、過去のツイートを取得するアプリケーションを作りたいと思ったら OAuth 2.0 の出番です。

Twitterアカウントを持っているリソース所有者が、アプリケーションに「ツイート権限」や「タイムライン取得権限」を認可(委譲)して、アプリケーションはその証としてアクセストークンを受け取ります。そして、このトークンを使ってTwitterにリクエストを投げてツイートしたり、タイムライン取得できるようになるってわけです。

 

OAuth 2.0 フロー

OAuthのトランザクションはトークンの発行とトークンの使用の2つに分割でき、標準的なOAuthのトランザクションは次のフローになります。

  1. リソース所有者はクライアントにリソース所有者の代わりとして振る舞ってほしいことを指示する。
    例. 私の代わりに、Twitter上のタイムラインを取得してください。
  2. クライアントは認可サーバー(Authorization Server)にリクエストをし、そこでリソース所有者にクライアントを認可するか判断させる
    例. 〇〇アプリケーション(クライアント)にタイムラインの取得を許可しますか?といった画面を表示する
  3. リソース所有者はクライアントを認可する
  4. クライアントは認可サーバーからトークンを受け取る
  5. クライアントはリソースサーバー(保護対象リソース)にトークンを提示する

OAuth超概要シーケンス図

 

基本的なフローは↑に貼ったシーケンス図の通りです。

このときポイントとなのは次の3つ。

ポイント

  • 認可サーバーでのリソース所有者の認証はクライアントからは見えない。エンドユーザーのクレデンシャルをクライアントに知られることはない。
  • トークンの発行と使用が分離されているため、認証方法が変わっても、クライアントは影響を受けない。(発行されたトークンを使うだけだから)
  • 認可サーバーでのリソース所有者の認証方法はなんでも良い。OAuthの仕様ではここでの認証技術には触れられていない。(OAuthは認可プロトコルで認証プロトコルではないから)
    • ID/PASSでも、SSOでも証明書でもどんな認証方法でもOK

実際には、クライアントがアクセストークンを取得するフローには4種類あって、それぞれで若干手順が異なってきます。

各フローについては、別記事で詳しくまとめたいと思います。

 

参考

以下の書籍・サイトを参考にしております。

OAuth徹底入門 セキュアな認可システムを適用するための原則と実践 はかなりオススメ。

例を添えて解説してくれますし、「認可サーバー」、「リソースサーバー」、「クライアント」のサンプルコードもあるのでOAuthのフローの動作を確認しながら(リクエストを見ながら)読み進めることができるので、理解が深まります。

 

イチオシ記事

1

自己紹介 フリーランスエンジニアをしているヨノと申します。 独学でプログラミングを学び、ソシャゲ・SaaS開発などを経て、2018年からフリーランスエンジニアとして活動しています。 主にバックエンド中 ...

2

はじめまして、フリーランスエンジニアのヨノと申します。 自己紹介 独学でプログラミングを学び、ソシャゲ・SaaS開発などを経て、2018年からフリーランスエンジニアとして活動しています。 主にバックエ ...

3

ネット上で色々言われているフリーランスエンジニア....。「本当はどうなの?」と思っている人は多いでしょう。 そこで本記事ではフリーランスエンジニア5年生の私が、ネット上の意見も引用しながら実態を解説 ...

-プログラミング学習