Clever Geek Handbook

OAuth 2.0は簡単に理解できます

OAuth 2.0ロゴ



ハブでOAuth 1.0について既に書いていますが、そのようなOAuth 2.0についての明確な説明はありませんでした。 以下に、OAuth 2.0の違いと利点、およびサイト、モバイルアプリケーション、デスクトップアプリケーションでの最適な使用方法について説明します。



OAuth 2.0とは



OAuth 2.0は、1つのサービス（アプリケーション）に別のサービスのユーザーリソースへのアクセス権を許可する許可プロトコルです。 このプロトコルにより、ユーザー名とパスワードを使用してアプリケーションを信頼する必要がなくなり、一度にすべてではなく、限られた権限セットを発行できます。





OpenIDとOAuthの違いは何ですか



この主題についてはすでに多くの説明があったという事実にもかかわらず、それはまだいくつかの誤解を引き起こしています。



OpenIDは認証を目的としています-つまり、この特定のユーザーが本人であることを理解するためです。 たとえば、OpenIDの助けを借りて、特定のOloloサービスはそこに入力したユーザーがMail.RuのRoma Novikovであることを理解できます。 次の認証で、オロロは再び彼を認識し、これが前回と同じローマであることを理解できるようになります。



OAuthは承認プロトコルです。つまり、オロロ自身がRomaに代わってMail.Ruで実行できるアクションに対する権利を発行できます。 同時に、承認後、Romaはアクションを実行するプロセスにまったく参加しない場合があります。たとえば、OloloはRominアカウントに写真を個別にアップロードできます。



OAuth 2.0の仕組み



最初のバージョンと同様に、OAuth 2.0はHTTP要求、リダイレクトなどの基本的なWebテクノロジーの使用に基づいています。したがって、OAuthの使用は、インターネットおよびブラウザーにアクセスできる任意のプラットフォームで可能です：サイト、モバイルおよびデスクトップアプリケーション、プラグインブラウザ用...



OAuth 1.0との主な違いはシンプルです。 新しいバージョンでは、かさばる署名スキームはありません。承認に必要なリクエストの数が減りました。



OAuthを使用したアプリケーションの操作の一般的なスキームは次のとおりです。

  1. 認可を受ける
  2. 安全なリソースへのアクセス


認可の結果はアクセストークン -特定のキー（通常は単なる文字セット）であり、その提示は保護されたリソースへのパスです。 最も単純な場合、HTTPSを介してアクセスされ、ヘッダーで、または取得されたアクセストークンをパラメーターの1つとして示します 。



プロトコルには、さまざまな状況に適したいくつかの許可オプションが記載されています。





サーバー側アプリケーションの承認



サーバー部分を持つアプリケーションの承認スキーム

  1. ログインページにリダイレクトする
  2. 認証ページで、ユーザーは権利の発行の確認を求められます
  3. ユーザーの同意がある場合、ブラウザーは、GETパラメーターに特別なキーを追加して、許可ページを開くときに指定されたURLにリダイレクトします- 許可コード
  4. アプリケーションサーバーは、取得した認証コードをパラメーターとしてPOST要求を実行します。 このリクエストはアクセストークンを返します


これは認証の最も難しいバージョンですが、サービスが認証を要求するアプリケーションを一意にインストールできるようにするだけです（これは最後のステップでサーバー間で通信するときに起こります）。 他のすべてのオプションでは、認可はクライアント上で完全に行われ、明らかな理由により、あるアプリケーションを別のアプリケーションに対してマスクすることが可能です。 これは、サービスAPIでOAuth認証を実装するときに考慮する必要があります。



例


Mail.Ru APIの例を以下に示しますが、ロジックはすべてのサービスで同じであり、認証ページのアドレスのみが変更されます。 要求はHTTPS経由で行う必要があることに注意してください。



ユーザーのブラウザを認証ページにリダイレクトします。 

 > GET / oauth / authorize？Response_type = code＆client_id = 464119＆
       redirect_uri = http％3A％2F％2Fexample.com％2Fcb％2F123 HTTP / 1.1
 >ホスト：connect.mail.ru


以下、client_idおよびclient_secretは、プラットフォームにアプリケーションを登録するときに取得される値です。



ユーザーが権利を発行すると、指定されたredirect_uriへのリダイレクトが発生します。 

 <HTTP / 1.1 302が見つかりました
 <場所：http://example.com/cb/123?code=DoRieb0y




OAuthを使用してサイトにログインを実装する場合、 CSRF攻撃を防ぐためにredirect_uriの各ユーザーに一意の識別子を追加することをお勧めします（例では、これは123です）。 コードを受け取ったら、この識別子が変更されておらず、現在のユーザーに対応していることを確認する必要があります。



受信したコードを使用して、サーバーからリクエストを実行してaccess_tokenを取得します。 

 > POST / oauth / token HTTP / 1.1
 >ホスト：connect.mail.ru
 > Content-Type：application / x-www-form-urlencoded
 > 
 > grant_type = authorization_code＆client_id = 464119＆client_secret = deadbeef＆code = DoRieb0y＆
   redirect_uri = http％3A％2F％2Fexample.com％2Fcb％2F123

 <HTTP / 1.1 200 OK
 <Content-Type：application / json
 <
 <{
 <"access_token"： "SlAV32hkKG"、
 <"token_type"： "bearer"、
 <"expires_in"：86400、
 <"refresh_token"： "8xLOxBtZp8"、
 <}




最後のリクエストはclient_secretを使用します。この場合、このクライアントはアプリケーションサーバーに保存され、リクエストが改ざんされていないことを確認します。



最後のリクエストの結果として、アクセスキー自体（ access_token ）、その「フェード」の時間（ expires_in ）、使用方法を決定するキーのタイプ（ token_type ）、および以下で詳細に説明するrefresh_tokenを取得します。 さらに、取得したデータを使用して、保護されたリソース（Mail.Ru APIなど）にアクセスできます。 

 > GET /platform/api?oauth_token=SlAV32hkKG&client_id=464119&format=json&method=users.getInfo&
       sig = ... HTTP / 1.1
 >ホスト：appsmail.ru


仕様の説明



完全なクライアントアプリケーションの承認



完全なクライアント支払いの承認スキーム

  1. 認証ページでビルトインブラウザーを開く
  2. ユーザーは、権利の付与の確認を求められます
  3. ユーザーが同意すると、ブラウザはフラグメント内のスタブページ（＃の後に）にリダイレクトし、そのURLにアクセストークンが追加されます
  4. アプリケーションはリダイレクトをインターセプトし、ページアドレスからアクセストークンを取得します


このオプションでは、アプリケーションのブラウザウィンドウを上げる必要がありますが、 アクセストークンの 認証コードを交換するためのサーバー側と追加のサーバー間呼び出しは必要ありません。



例


認証ページでブラウザーを開きます。 

 > GET / oauth / authorize？Response_type = token＆client_id = 464119 HTTP / 1.1
 >ホスト：connect.mail.ru




ユーザーが権限を付与すると、標準スタブページへのリダイレクトが発生します。Mail.Ruの場合はconnect.mail.ru/oauth/success.htmlです。 

 <HTTP / 1.1 302が見つかりました
 <場所：http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer&
             expires_in = 86400＆refresh_token = yaeFa0gu




アプリケーションは最後のリダイレクトをインターセプトし、 acess_tokenアドレスから取得し、それを使用して保護されたリソースにアクセスする必要があります。



仕様の説明



ログインおよびパスワード認証



ログインとパスワードによる承認は、 アクセストークンを返す単純なPOST要求を表します 。 このようなスキームは新しいものではありませんが、一般性のために標準に挿入されており、他の許可オプションが利用できない場合にのみ使用することをお勧めします。



例 


 > POST / oauth / token HTTP / 1.1
 >ホスト：connect.mail.ru
 > Content-Type：application / x-www-form-urlencoded
 > 
 > grant_type=password&client_id=31337&client_secret=deadbeef&username=api@corp.mail.ru&
  パスワード= qwerty

 <HTTP / 1.1 200 OK
 <Content-Type：application / json
 <
 <{
 <"access_token"： "SlAV32hkKG"、
 <"token_type"： "bearer"、
 <"expires_in"：86400、
 <"refresh_token"： "8xLOxBtZp8"、
 <}


仕様の説明



以前の認証を復元する



通常、 アクセストークンの有効期間は限られています。 これは、たとえば、開いているチャネルを介して送信される場合に役立ちます。 アクセストークンの有効期限後にユーザーに認証を強制しないようにするために、上記のすべてのオプションで、 アクセストークンに加えて、 更新リフレッシュトークンも返すことができます。 その上で、ログインとパスワードによる認証と同様に、HTTPリクエストを使用してアクセストークンを取得できます。



例 


 > POST / oauth / token HTTP / 1.1
 >ホスト：connect.mail.ru
 > Content-Type：application / x-www-form-urlencoded
 > 
 > grant_type = refresh_token＆client_id = 31337＆client_secret = deadbeef＆refresh_token = 8xLOxBtZp8

 <HTTP / 1.1 200 OK
 <Content-Type：application / json
 <
 <{
 <"access_token"： "Uu8oor1i"、
 <"token_type"： "bearer"、
 <"expires_in"：86400、
 <"refresh_token"： "ohWo1ohr"、
 <}


仕様の説明



OAuth 2.0の短所



このすべての美しさで、軟膏にハエがあります、それなしでどこに？



OAuth 2.0は進化する標準です。 これは、仕様がまだ確立されておらず、絶えず変更されていることを意味します。 したがって、今すぐ標準をサポートすることに決めた場合は、仕様の変更に応じてそのサポートを提出する必要があるという事実に備えてください。 一方、それはまた、標準を作成するプロセスに参加し、アイデアをもたらすことができることを意味します。



OAuth 2.0セキュリティは、主にSSLベースです。 これにより、開発者の生活は大幅に簡素化されますが、追加のコンピューティングリソースと管理が必要になります。 これは、負荷の高いプロジェクトでは重大な問題になる可能性があります。



おわりに



OAuthは、インターネットの基本原則に基づいた単純な認証標準であり、ほとんどすべてのプラットフォームで認証を使用できます。 この標準は最大のサイトをサポートしており、その人気が高まるだけであることは明らかです。 サービスのAPIについて考えている場合は、OAuth 2.0を使用した承認が適切な選択です。



一部では、Mail.Ru APIにOAuth 2.0を実装しました。プロトコル機能を使用して、Mail.Ruに統合されたクライアントとサービスを実装できます。



参照資料





Dmitry Bitman-プラットフォームマネージャーMail.Ru


More articles:


All Articles