[[Open棟梁Project>http://opentouryo.osscons.jp/]] - [[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。

-[[戻る>クレームベース認証#k66961ce]]
-[[戻る>OpenID / OAuth / OpenID Connect]]

* 目次 [#qc1590f2]
#contents

*概要 [#ff7046a2]
-認可レイヤー(AuthorizationServer)の設置により、ResourceOwnerとClientを分離することができる。
ここでは、基本的に、OAuth 2.0について言及する。

-これにより、[[ResourceOwnerのCredentials>#m0ca183e]]をClientに渡す必要が無くなる。
OAuth 2.0は、認証ではなく認可のためのプロトコル(権限委譲プロトコル)。

-[[Authorization Server>#a2ff14fb]]の設置により、[[Resource Owner>#qe857228]]と[[Client>#b4b4c0bd]]を分離することができる。

-これにより、[[Resource OwnerのCredentials>#m0ca183e]]を[[Client>#b4b4c0bd]]に渡す必要が無くなる。

-[[Resource Owner>#qe857228]]は、[[Authorization Server>#a2ff14fb]]によって、[[Client>#b4b4c0bd]]の[[Resource Server>#n1c92dc2]]へのアクセスを認可できるようになる。

*変遷 [#k3aeda5b]
**OAuth 1.0 [#eb4fd2ef]
-OpenIDを使ってTwitterやMa.gnoliaのAPIの認証委譲する方法を議論を開始。

-2007/4~
OAuthのコミュニティが誕生。

-2007/7~
OAuthの仕様の草案が完成。

-2007/10~
OAuth Core 1.0 の最終草案がリリース。

-2008/11~
第73回のIETF会合でOAuthの非公式会合も開かれ、~
IETFにOAuthプロトコルを提案するかどうかを議論。

-2009/4/23~
OAuth 1.0のセキュリティ問題が判明。~
この問題は、OAuth 1.0aで修正された。

**OAuth 2.0 [#h8e684ba]
-OAuth 1.0とは後方互換性を持たない。
-次世代のOAuthプロトコルとして、2012年にRFCとして発行された。

**OAuth 1.0とOAuth 2.0の違い [#s44d10cb]
***概要 [#hcedd1fd]
+HTTPSを必須にし、署名をなくし、Token取得も簡略化
+[[Access Token>#jb722a87]]のみでリソース取得が可能に
+Webアプリも含め、4つのClient Profileを仕様化
++Webサーバ(Web Server)~
Webアプリケーション
++User Agentベースアプリケーション~
WWWブラウザ上のJavaScript
++ネイティブアプリ(Native Application)~
モバイルやデスクトップアプリ(ガイドライン程度しか定義されていない)
++自立クライアント(Autonomous)~
既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。

***参考 [#e6a50b1d]
-OAuth 2.0でWebサービスの利用方法はどう変わるか(2-3)- @IT~
http://www.atmarkit.co.jp/fsmart/articles/oauth2/02.html

-OAuth 2.0 の仕組みと認証方法 | murashun.jp~
https://murashun.jp/blog/20150920-01.html#chapter-3

-初心者のためのOAuth — OAuthの基本のキ | Rriver~
https://parashuto.com/rriver/development/learning-oauth-basics

-How is OAuth 2 different from OAuth 1? - Stack Overflow~
http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1

**OAuth 2.0とOpenID Connectの違い [#z37db375]
***概要 [#s805c8ce]
-Tokenが[[JWT]]アサーション形式で暗号化・署名される。

-新しく、Hybrid Flowが追加されている。
--[[Authorization Codeグラント種別>#yfeb403d]] ---> [[Authorization Code Flow>OpenID Connect#mcde509a]]
--[[Implicitグラント種別>#m5c2d510]] ---> [[Implicit Flow>OpenID Connect#e7adf5c2]]
--上記の組合せたようなグラント種別 ---> [[Hybrid Flow>OpenID Connect#l565139a]]

-コレ以外にも、多数のオプションが追加されている。

***参考 [#s6e988c9]
-[[OpenID Connect]]

-OpenID Connect 入門~
〜コンシューマーにおけるID連携のトレンド〜
--OAuth 2.0 Authorization Code Flow~
---http://www.slideshare.net/kura_lab/openid-connect-id/21
---~ http://www.slideshare.net/kura_lab/openid-connect-id/27
--OpenID Connect Authorization Code Flow~
---http://www.slideshare.net/kura_lab/openid-connect-id/28
---~ http://www.slideshare.net/kura_lab/openid-connect-id/78

*(OAuth 2.0 の)詳細 [#r0608873]
**登場人物 [#zb38b595]
|項番|名称|実体例|やること|h
|1|ResourceOwner|ユーザ(人間)|[[ResourceOwnerのCredentials>#m0ca183e]]を入力してリソースにアクセスする。|
|2|Client|Program(Webブラウザ, Webアプリケーション, etc.)|1、3、4を繋ぐ忙しいプログラム(だから[[クレームベース認証]]は難しい)|
|3|AuthorizationServer|認証・認可のサーバー機能|認証チケットと[[Access Token>#jb722a87]]の発行を行うWebアプリケーション。|
|4|ResourceServer|リソースアクセスを提供するサーバー機能、 AuthorizationServerと別でも良い|[[Access Token>#jb722a87]]を受けてリソースアクセスを提供するWebアプリケーション。|
***Resource Owner [#qe857228]
-実体例:ユーザ(人間)
-やること:~
[[Resource OwnerのCredentials>#m0ca183e]]を入力してリソースにアクセスする。

***Client [#b4b4c0bd]
-実体例:
--Resource ServerにアクセスするClient。
--Program
---Webブラウザ
---スマホ ネイティブ
---Webアプリケーション
---, etc.

-やること:
--Authorization Serverの認可を受けてResource Serverのリソースにアクセスする。
--認可レイヤの設置により、認証・認可の役割が分割されたため、~
Resource Owner, Authorization Server, Resource Serverを繋ぐ~
忙しいプログラムになった(だから[[OAuth]]はClient側でも難しい)。

***Authorization Server [#a2ff14fb]
-実体例:認証・認可のサーバー機能(Webアプリケーション)

-やること:
--Authorization Server用の認証チケットの発行を行う。
--Resource Server用の[[Access Token>#jb722a87]]の発行を行う。

***Resource Server [#n1c92dc2]
-実体例:
--リソースアクセスを提供するサーバー機能(WebAPIなど)
--Authorization Serverと別でも良い

-やること:~
[[Access Token>#jb722a87]]を受けてリソースアクセスを提供する。

**プロトコル・フロー [#g723492b]
 +--------+                               +---------------+
 |        |--(A)- Authorization Request ->|   Resource    |
 |        |                               |     Owner     |
 |        |<-(B)-- Authorization Grant ---|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(C)-- Authorization Grant -->| Authorization |
 | Client |                               |     Server    |
 |        |<-(D)----- Access Token -------|               |
 |        |                               +---------------+
 |        |
 |        |                               +---------------+
 |        |--(E)----- Access Token ------>|    Resource   |
 |        |                               |     Server    |
 |        |<-(F)--- Protected Resource ---|               |
 +--------+                               +---------------+

***(A) Authorization Request [#b5726bb0]
ResourceOwnerは、Clientを経由して、AuthorizationServer(の認証画面)で認証する。
Resource Ownerは、Clientを経由して、Authorization Server(の認証画面)で認証する。

***(B) Authorization Grant [#m6a4436a]
認証後、Clientは、AuthorizationServerの[[認可エンドポイント>#s820b1ab]]で認可グラントを受け取る。
認証後、Clientは、Authorization Serverの[[認可エンドポイント>#s820b1ab]]で認可グラントを受け取る。

***(C) Authorization Grant [#m041f58e]
Clientは、AuthorizationServerの[[Tokenエンドポイント>#s820b1ab]]に認可グラントを提示することで、[[Access Token>#jb722a87]]を要求する.
Clientは、Authorization Serverの[[Tokenエンドポイント>#s820b1ab]]に認可グラントを提示することで、[[Access Token>#jb722a87]]を要求する.

***(D) Access Token [#pcf3e60f]
AuthorizationServerは、Clientと 認可グラントが正当であれば、Clientに[[Access Token>#jb722a87]]を発行する。
Authorization Serverは、Clientと 認可グラントが正当であれば、Clientに[[Access Token>#jb722a87]]を発行する。

***(E) Access Token, (F) Protected Resource [#b1d7b608]
Clientは、ResourceServerに[[Access Token>#jb722a87]]を提示してProtected Resourceにアクセスする。
Clientは、Resource Serverに[[Access Token>#jb722a87]]を提示してProtected Resourceにアクセスする。

**フロー [#c8a23ceb]
以下4つのグラント種別に対応するフローがある。
***★ 参考 [#p9f64095]
[[ココのスライド>#s6e988c9]]が参考になる。

**グラント種別毎のフロー [#c8a23ceb]
以下、4つのグラント種別に対応するフローがある。

***Authorization Codeグラント種別 [#yfeb403d]
-概要
--WebアプリケーションのWebブラウザから使うフロー。
---認証画面で[[ResourceOwnerの認証>#m0ca183e]]をした後、
--[[Confidentialクライアント>#q08180e3]]のサーバ側から使うフロー。
---認証画面で[[Resource Ownerの認証>#m0ca183e]]をした後、
---[[認可エンドポイント>#s820b1ab]]の"画面"でリソース・アクセスを認可、
---[[Redirectエンドポイント>#ja887509]]で[[Access Token>#jb722a87]]と[[Refresh Token>#r3e36f53]]を取得し、
---最後に・・・、
---[[Redirectエンドポイント>#ja887509]]で取得した仲介コードを取得する。
---[[Tokenエンドポイント>#s820b1ab]]で仲介コードを使用して~
[[Access Token>#jb722a87]]と[[Refresh Token>#r3e36f53]]を取得し、
---最後に[[Access Token>#jb722a87]]を使用してResource Serverにアクセスする。

-特徴
--[[ResourceOwnerのCredentials>#m0ca183e]]はClientに共有されない。
--Confidential Clientに最適化される。
--Authorization ServerはClientを認証する。
---仲介コード(code)を使用することで、[[Access Token>#jb722a87]]をUser Agentに露見させずに処理可能。
---[[Access Token>#jb722a87]]の露見防止には、Clientのエンドポイント・コンテンツの実装に依存する。

-通信~
RFCを読んだほうが良い。
[[RFC>#v698197b]]を読んだほうが良い。
--[[認可リクエスト>http://openid-foundation-japan.github.io/rfc6749.ja.html#code-authz-req]]
---[[認可レスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#code-authz-resp]]
--[[アクセストークン・リクエスト>http://openid-foundation-japan.github.io/rfc6749.ja.html#token-req]]
---[[アクセストークン・レスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor25]]

***Implicitグラント種別 [#m5c2d510]
-概要
--JavaScriptなどから使うフロー。
---認証画面で[[ResourceOwnerの認証>#m0ca183e]]をした後、
---[[認可エンドポイント>#s820b1ab]]でリソース・アクセスを認可、
---[[Redirectエンドポイント>#ja887509]]で[[Bearer Token>#i5f79713]]を取得し、
---最後に[[Bearer Token>#i5f79713]]を使用してリソースサーバーへアクセスする。
--[[Publicクライアント>#q08180e3]]のクライアント側から使うフロー(ただし、サーバ側のエンドポイントは必要)。
---認証画面で[[Resource Ownerの認証>#m0ca183e]]をした後、
---[[認可エンドポイント>#s820b1ab]]でリソース・アクセスを認可、[[Access Token>#jb722a87]]を取得する。
---(この間のRedirectで、[[Access Token>#jb722a87]]が露見する。)
---[[Redirectエンドポイント>#ja887509]]では、[[Access Token>#jb722a87]]を[[Publicクライアント>#q08180e3]]に返す。
---最後に[[Access Token>#jb722a87]]を使用してResource Serverにアクセスする。

-特徴
--AuthorizationServerはClientを認証しない。
--JavaScript、スマホネイティブなどのPublic Clientに最適化される。
--認可コードといった仲介のCredentialを使用しないため応答性に優れる。
--反面、[[Bearer Token>#i5f79713]]が露見するセキュリティのトレードオフがある([[10.3>http://openid-foundation-japan.github.io/rfc6749.ja.html#AccessTokenSecurity]]、[[10.16>http://openid-foundation-japan.github.io/rfc6749.ja.html#ImplicitImpersonation]])。
--Authorization ServerはClientを認証しない。
---[[認可エンドポイント>#s820b1ab]]と[[Redirectエンドポイント>#ja887509]]間のラウンドトリップが少なく、応答性に優れる。
---反面、仲介コード(code)を使用しないため、[[Access Token>#jb722a87]]が、~
User Agentに露見するセキュリティのトレードオフがある([[10.3>http://openid-foundation-japan.github.io/rfc6749.ja.html#AccessTokenSecurity]]、[[10.16>http://openid-foundation-japan.github.io/rfc6749.ja.html#ImplicitImpersonation]])。
---[[Access Token>#jb722a87]]の拡散防止には、Clientのエンドポイント・コンテンツの実装に依存する。

-通信~
[[RFC>#v698197b]]を読んだほうが良い。
--[[認可リクエスト>http://openid-foundation-japan.github.io/rfc6749.ja.html#implicit-authz-req]]
---[[アクセストークン・レスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#implicit-authz-resp]]

***Resource Owner Password Credentialsグラント種別 [#zfff6f89]
-概要
--[[ベース クライアント セキュリティ モデル]]みたいなもん。
--[[Resource OwnerのCredentials>#m0ca183e]]を送って[[Bearer Token>#i5f79713]]を取得。
--[[ベース クライアント セキュリティ モデル]]みたいなもんだが、~
以下のようにあるため、本グラント種別の利用は、特殊なケースに留める。
>「この認可タイプを使用可能にするときには特に注意を払い、~
他のフローが実行可能でない場合にのみ許可する必要があります。」

--[[Resource OwnerのCredentials>#m0ca183e]]をClientに送る。
--Clientは、[[Resource OwnerのCredentials>#m0ca183e]]を[[認可エンドポイント>#s820b1ab]]に送る。
--Clientは[[Access Token>#jb722a87]]を取得してResource Serverにアクセスする。

-特徴
--ResourceOwnerとClientの間に高い信頼関係があること。
--[[Authorization Codeグラント種別>#yfeb403d]]のフローを使用できないようなケースで使用する。
--[[Resource OwnerのCredentials>#m0ca183e]]をClientに送ってしまう。
--従って、[[Confidentialクライアント>#q08180e3]]から使用する。
---Resource OwnerとClientの間に高い信頼関係があること。
---Authorization Serverは、Clientを認証すること。
--以下のような、特殊なケースに留める。
---OAuth2.0 への移行段階。
---[[Authorization Codeグラント種別>#yfeb403d]]のフローを使用できないようなケース。~
例えば、[[Publicクライアント>#q08180e3]]からClientのサーバ側エンドポイント以外に直接アクセスできないようなケース。

-通信~
[[RFC>#v698197b]]を読んだほうが良い。
--[[認可リクエストとレスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor26]]
--[[アクセストークン・リクエスト>http://openid-foundation-japan.github.io/rfc6749.ja.html#password-tok-req]]
---[[アクセストークン・レスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor27]]

***Client Credentialsグラント種別 [#o9473080]
-概要
--[[サーバ信頼セキュリティ モデル]]みたいなもん。
--[[ClientのCredentials>#i7b73962]]を送って[[Bearer Token>#i5f79713]]を取得。
--Clientは、[[ClientのCredentials>#i7b73962]]を[[認可エンドポイント>#s820b1ab]]に送る。
--Clientは[[Access Token>#jb722a87]]を取得してResource Serverにアクセスする。

-特徴
--Clientのリソースである場合に使用する。
--若しくは、Clientと AuthorizationServer間で調整済みのリソースである場合に使用する。
--Clientと Authorization Server間で調整済みの、~
Clientの保有するリソースにアクセスする場合に使用する。
--従って、[[Confidentialクライアント>#q08180e3]]から使用する。
---Authorization Serverは、Clientを認証すること。

-通信~
[[RFC>#v698197b]]を読んだほうが良い。
--[[認可リクエストとレスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor28]]
--[[アクセストークン・リクエスト>http://openid-foundation-japan.github.io/rfc6749.ja.html#client-req]]
---[[アクセストークン・レスポンス>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor29]]

**Clientについて [#aab02700]
***種類 [#q08180e3]
-[[Client Credentials>#i7b73962]]の機密性保持能力
--Confidential~
-[[Client Credentials>#i7b73962]]の機密性保持能力による分類

--Confidentialクライアント~
[[Client Credentials>#i7b73962]]の機密性を維持可能なClient
---アクセスの制限されたサーバー

--Public~
--Publicクライアント~
[[Client Credentials>#i7b73962]]の機密性を維持不可能なClient
---WWWブラウザ
---ネイティブ・アプリケーション
---ResourceOwnerのデバイスにインストールされたアプリケーション
---Resource Ownerのデバイスにインストールされたアプリケーション

-Client Profile
--Confidential
-Client Profile(クライアント属性)による分類

--Confidentialクライアント
---Webアプリケーション
--Public
---ネイティブアプリケーション
---WWWブラウザなどのUserAgentベースアプリケーション

***登録 [#keaaae10]
[[クライアント識別子>#i7b73962]]を使用して、Clientを登録する。
--Publicクライアント
---ネイティブ・アプリケーション
---SPAなどのUser Agentベースアプリケーション(WWWブラウザ上のJavaScript)

**トークン(認可用のCredentials) [#vc4e6813]
***事前登録 [#keaaae10]
-[[クライアント識別子>#i7b73962]]を使用して、Clientを事前登録する。
-[[Authorization Code>#yfeb403d]]や、[[Implicitグラント種別>#m5c2d510]]の[[Redirectエンドポイント>#ja887509]]
--client_idに対応する[[Redirectエンドポイント>#ja887509]]のURL(絶対パスを)事前登録する。
--動的設定では部分一致をサポートするが、オープンリダイレクト脆弱性がある。

**認可用のCredentials(Token) [#vc4e6813]

***Access Token [#jb722a87]
[[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor8]]を読むと、
-保護されたリソースにアクセスするために使用されるCredential。
-AuthorizationServerによってClientに対して発行されるランダムな文字列。
-Authorization ServerによってClientに対して発行されるランダムな文字列。
-アクセス範囲とアクセス期間を表す。
-発行はResourceOwnerによって許可される。
-AuthorizationServerが発行し、ResourcesServerが利用。
-発行はResource Ownerによって許可される。
-Authorization Serverの[[Tokenエンドポイント>#s820b1ab]]が発行し、
-Resource Serverへの要求に対して、以下の様な形式で送信される。

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer XXXXXXXXXX

***Refresh Token [#r3e36f53]
[[RFC>http://openid-foundation-japan.github.io/rfc6749.ja.html#anchor9]]を読むと、
-[[Access Token>#jb722a87]]の無効化・期限切れの際に新しい[[Access Token>#jb722a87]]取得するために使用されるCredential。
-AuthorizationServerによってClientに対して発行されるランダムな文字列。
-Authorization ServerによってClientに対して発行されるランダムな文字列。
-[[Refresh Token>#r3e36f53]]の発行はオプションであり、[[Access Token>#jb722a87]]に[[Refresh Token>#r3e36f53]]も含まれる。
-[[Refresh Token>#r3e36f53]]と異なり、ResourcesServerに送信されることはない。
-[[Access Token>#jb722a87]]と異なり、Resource Serverに送信されることはない。

***Bearer Token [#i5f79713]
-署名無しトークン([[Access Token>#jb722a87]]は基本的にBearer Token>#jb722a87)
-トークンが誰に対して発行されたのかを確認せずに、~
「トークンを持っていること」をベースに API 利用を許可する。
-∴ 利用する際、暗号鍵の所持を証明するよう要求されない。
***[[Accessトークンのタイプ>トークン#b38de47f]] [#i5f79713]

-参考
--OAuth 2.0のbearer tokenの最新仕様を調べたらあまり変わってなかった - r-weblife~
http://d.hatena.ne.jp/ritou/20110402/1301679908
---The OAuth 2.0 Authorization Framework: Bearer Token Usage(日本語)~
http://openid-foundation-japan.github.io/rfc6750.ja.html

**認証用のCredentials [#wdad8a4e]

***ResourceOwner [#m0ca183e]
仕様の外(ユーザID、パスワードなどを使用してResourceOwnerを認証)
***Resource Owner [#m0ca183e]
Resource Ownerの認証用のCredentialsはOAuth 2.0 仕様の外~
(Authorization ServerはユーザID、パスワードなどを使用してResource Ownerを認証)

***Client [#i7b73962]
-ベーシック認証
Clientの認証用のCredentials~
(Authorization ServerはこれによりClientを認証)

-クライアント識別子
--client_id(露見する)
--client_secret(露見しない、させない)
-クライアント識別子~
クライアント識別子(2つのセット)の情報は、URIで送信しない。
--client_id(1つだけの場合、URIに露見する)
--client_secret(URIに露見しない、させない)

**エンドポイント [#h4dcb0c7]
***AuthorizationServer上 [#s820b1ab]
-認証方法
--ベーシック認証などのパスワードベースのHTTP認証スキーム
--HTTP認証スキームを使用できない場合にPOSTを使用する(非推奨)。

**エンドポイントの種類 [#h4dcb0c7]
URLは仕様で規定されない。

***Authorization Server上のエンドポイント [#s820b1ab]

-認可エンドポイント
--ResourceOwnerを認可するエンドポイント(認証画面ではないので注意)。
--Authorization Code, Implicitグラント種別で使用する。
--概要
---Resource Ownerを認可するエンドポイント
---認証画面ではないので注意(認証結果を見て認可する)。
---仲介コードや、[[Access Token>#jb722a87]]を発行するエンドポイント。
--特徴
---HTTPSのGETを使用する。
---[[Authorization Code>#yfeb403d]]や、[[Implicitグラント種別>#m5c2d510]]で使用する。

-Tokenエンドポイント
--[[Access Token>#jb722a87]]を発行するエンドポイント。
--Implicitグラント種別を除く、他の全てのグラント種別で使用する。
---Implicitグラント種別では、Redirectエンドポイントで[[Access Token>#jb722a87]]を返す。
--URLは仕様で規定されない。HTTPSのPOSTを使用する。
--概要~
[[Access Token>#jb722a87]]・[[Refresh Token>#r3e36f53]]を発行するエンドポイント。
--特徴
---HTTPSのPOSTを使用する。
---[[Implicitグラント種別>#m5c2d510]]を除く、他の全てのグラント種別で使用する。~
[[Implicitグラント種別>#m5c2d510]]では、[[認可エンドポイント>#s820b1ab]]で[[Access Token>#jb722a87]]を返す。

***Client上 [#ja887509]
-Redirectエンドポイント
--コンテンツには、3rd partyのscriptを含めるべきでない。
--Client自身のscriptが初回に実行されるようにすること。
--URIからCredentialを抽出し、露見しないように他へPOSTするなどすること。
***Client上のエンドポイント [#ja887509]
Redirectエンドポイント

*変遷 [#k3aeda5b]
**OAuth 1.0 [#eb4fd2ef]
-OpenIDを使ってTwitterやMa.gnoliaのAPIの認証委譲する方法を議論を開始。
-2007/4にOAuthのコミュニティが誕生。
-2007/7にOAuthの仕様の草案が完成。
-2007/10/3に、より正式な仕様であるOAuth Core 1.0 の最終草案がリリース。
-2008/11、第73回のIETF会合でOAuthの非公式会合も開かれ、~
さらなる標準化に向けてIETFにOAuthプロトコルを提案するかどうかを議論。
-2009/4/23、OAuth 1.0のセキュリティ問題が判明。この問題は、OAuth 1.0aで修正された。
-概要~
エンドポイント・コンテンツを返す。

**OAuth 2.0 [#h8e684ba]
-OAuth 1.0とは後方互換性を持たない。
-次世代のOAuthプロトコルとして、2012年にRFCとして発行された。
-特徴
--HTTPSのGETを使用する。
--[[Authorization Code>#yfeb403d]]や、[[Implicitグラント種別>#m5c2d510]]で使用する。

**OAuth 1.0とOAuth 2.0の違い [#s44d10cb]
-OAuth 2.0でWebサービスの利用方法はどう変わるか(2-3)- @IT~
http://www.atmarkit.co.jp/fsmart/articles/oauth2/02.html
+HTTPSを必須にし、署名をなくし、トークン取得も簡略化
+[[Access Token>#jb722a87]]のみでリソース取得が可能に
+Webアプリも含め、4つのClient Profileを仕様化
++Webサーバ(Web Server)~
Webアプリケーション
++ユーザーエージェント(User-Agent) ~
JavaScript
++ネイティブアプリ(Native Application)~
モバイルやデスクトップアプリ(ガイドライン程度しか定義されていない)
++自立クライアント(Autonomous)~
既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー。
-注意点
--[[Authorization Code>#yfeb403d]]では、なるべくエンドポイント・コンテンツにTokenが露見しないようにする。
--Implicitグラントなど、Tokenがコンテンツに露見してしまう場合、以下に従い拡散を防止する。
---コンテンツには、3rd partyのscriptを含めるべきでない。
---Client自身のscriptが初回に実行されるようにすること。
---URIからTokenを抽出し、露見しないように他へPOSTしBodyに含めるなどする。

**OAuth 2.0とOpenID Connectの違い [#z37db375]
-[[OpenID Connect]]を参考にする。
-[[Bearer Token>#i5f79713]]ではなく、各種トークンやクレームが暗号化・署名される。
--Token:エンコード&署名される。
--Claim:暗号化される。
**Requestパラメタ [#xd504f07]

*セキュリティ [#v33a7e19]
セキュリティに関する考察
***response_typeパラメタ [#l1d2572d]
[[認可エンドポイント>#s820b1ab]]にGETで送付する。~
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。

-OAuth 2.0の概要とセキュリティ~
http://www.slideshare.net/charlier-shoe/oauth-20-29540466
|項番|グラント種別|パラメタ値|意味|h
|1|[[Authorization Code>#yfeb403d]]|code|仲介コードを要求|
|2|[[Implicit>#m5c2d510]]|token|[[Access Token>#jb722a87]]を要求|

**Authorization Codeグラント種別 [#f4d89342]
-参考:[[OpenID Connect]]によって、[[追加された、response_type>OpenID Connect#aff816e3]]。

***Open Redirector [#ycb0a43b]
-第3回 Webセキュリティのおさらい~
その3 CSRF・オープンリダイレクト・クリックジャッキング:~
JavaScriptセキュリティの基礎知識|gihyo.jp … 技術評論社~
http://gihyo.jp/dev/serial/01/javascript-security/0003?page=2
***client_id, client_secretパラメタ [#ha9ff05e]
Clientの識別や認証のために、色々な所で使用されるパラメタ。

-対策
--Server は、redirect_uri は事前登録必須 + 完全一致にする。
-[[コチラ>#i7b73962]]を参照。

***Covert Redirect [#gc1850ca]
既知の問題点を組み合わせた攻撃手法。
-用途
--[[認可エンドポイント>#s820b1ab]]
---client_idとredirect_uriの対応をチェックする。
--[[Redirectエンドポイント>#ja887509]]
---次の[[Tokenエンドポイント>#s820b1ab]]に渡す。
--[[Tokenエンドポイント>#s820b1ab]]
---Clientの認証を行なう。

以下の2つが組み合わさって成立する。
-Server 側の甘めの redirect_uri 検証
-Client 側が内包する open redirector
***redirect_uriパラメタ [#t71d0e79]
client_idに対応する[[Redirectエンドポイント>#ja887509]]を指定するために指定するパラメタ。

-OAuth 2.0 の脆弱性 (!?) "Covert Redirect" とは - OAuth.jp~
http://oauth.jp/blog/2014/05/07/covert-redirect/
--[[前述の対策を行う。>#ycb0a43b]]
--Client は、state パラメータをチェックする。
-[[Redirectエンドポイント>#ja887509]]を使用する、[[Authorization Code>#yfeb403d]]や、[[Implicitグラント種別>#m5c2d510]]で使用する。

state パラメタとは、
-[[認可エンドポイント>#s820b1ab]]にGETを送付するときに、部分一致するオプション値として絶対パスで指定する。

-OAuth 2.0のstateとredirect_uriとOpenID ConnectのnonceとID Tokenについて - r-weblife~
-指定した際は、[[Tokenエンドポイント>#s820b1ab]]まで、引き継がれチェックに使用される。~
[[認可エンドポイント>#s820b1ab]]に渡した値と同じであることを確認する必要がある。

***grant_typeパラメタ [#p23cde9e]
[[Tokenエンドポイント>#s820b1ab]]にPOSTを送付するときに指定するパラメタ。~
以下のように、グラント種別毎に、決まったパラメタを指定する必要がある。

|項番|グラント種別|パラメタ値|h
|1|[[Authorization Code>#yfeb403d]]|authorization_code|
|2|[[Resource Owner Password Credentials>#zfff6f89]]|password|
|3|[[Client Credentials>#o9473080]]|client_credentials|
|4|上記1、2、3のグラント種別でRefreshトークンを使用する際|refresh_token|

***scopeパラメタ [#qd3e1385]

-[[Authorization Codeグラント種別>#yfeb403d]]
--[[認可エンドポイント>#s820b1ab]]にGETで送付する。
--送信前に、画面で認可scopeをResource Ownerに提示する。

-[[Implicitグラント種別>#m5c2d510]]
--[[認可エンドポイント>#s820b1ab]]にGETで送付する。
--異なるscopeの[[Access Token>#jb722a87]]を取得した場合、Responseにscopeパラメタを付与する。

-[[Resource Owner Password Credentialsグラント種別>#zfff6f89]]
--[[Tokenエンドポイント>#s820b1ab]]にPOSTで送付する。
--異なるscopeの[[Access Token>#jb722a87]]を取得した場合、Responseにscopeパラメタを付与する。

-[[Client Credentialsグラント種別>#o9473080]]
--[[Tokenエンドポイント>#s820b1ab]]にPOSTで送付する。
--異なるscopeの[[Access Token>#jb722a87]]を取得した場合、Responseにscopeパラメタを付与する。

***stateパラメタ [#wbfa8d08]
[[CSRF>#bd3a67e8]]のセキュリティ対策に使用が推奨されるパラメタ。

-概要
--[[認可エンドポイント>#s820b1ab]]にGETを送付するときに指定する。
--[[Redirectエンドポイント>#ja887509]]を使用する、[[Authorization Code>#yfeb403d]]や、[[Implicitグラント種別>#m5c2d510]]で使用する。
--以降のやり取りでも引き継がれて使用される(値は変更しないこと)。

-要件
--推測困難な文字列である必要がある。(ワンタイム性は必須ではない)

-参考
--OAuth 2.0のstateとredirect_uriとOpenID ConnectのnonceとID Tokenについて - r-weblife~
http://d.hatena.ne.jp/ritou/20121008/1349695124
--CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例 - 徳丸浩の日記(2011-01-27)~
---CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例 - 徳丸浩の日記(2011-01-27)~
http://www.tokumaru.org/d/20110127.html

ザックリ言って、
**Responseパラメタ [#idca7e43]
code, access_token, refresh_token

-推奨される
-CSRF対策の
-推測困難な文字列
--(ワンタイム性は必須ではない)
***[[認可エンドポイント>#s820b1ab]] [#d9f01ea3]
|項番|パラメタ値|意味|h
|1|code|access_tokenを取得するためのtokenで、&br;[[Authorization Codeグラント種別>#yfeb403d]]でのみ使用する。|

と言うモノらしい。
***[[Tokenエンドポイント>#s820b1ab]] [#u2222b3c]
|項番|パラメタ値|意味|h
|2|access_token|[[コチラを参照>#jb722a87]]|
|3|refresh_token|[[コチラを参照>#r3e36f53]]|

**Implicitグラント種別 [#c9029c4e]
「OAuth 2.0 の implicit grant flow を認証に使うと、車が通れる程どてかいセキュリティ・ホールが開く。」らしい。
**Request & Responseの例 [#y77c50cc]

この、セキュリティ・ホールとは、
***[[認可エンドポイント>#s820b1ab]] [#y09a8594]

-単なる OAuth 2.0 を認証に使うと、~
車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone~
https://www.sakimura.org/2012/02/1487/
-[[Authorization Code>#yfeb403d]]

ザックリ言って、
--リクエスト例
  GET /authorize?response_type=code&client_id=XXXX&state=YYYY
      &redirect_uri=http... HTTP/1.1
  Host: ...

-攻撃者の構築したRP(A)は、access_tokenを収集する。
-攻撃者は、 access_token 置換え攻撃により、~
RP(B)にログイン(若しくはRP(B)経由でリソース・アクセス)できる。
--成功レスポンス例
  HTTP/1.1 302 Found
  Location: http...?code=YYYY&state=ZZZZ

と言うモノらしい。
--失敗レスポンス例
  HTTP/1.1 302 Found
  Location: http...#error=access_denied&state=YYY

この問題に対しては、
-[[Implicit>#m5c2d510]]

-OAuth 2.0 Implicit Flowをユーザー認証に利用する際のリスクと対策方法について #idcon - r-weblife~
http://d.hatena.ne.jp/ritou/20120206/1328484575
--Idcon11 implicit demo~
http://www.slideshare.net/ritou/idcon11-implicit-demo
--リクエスト例
  GET /authorize?response_type=token&client_id=XXX&state=YYY&redirect_uri=http... HTTP/1.1
  Host: ...

以下のように対策できる。
--成功レスポンス例
  HTTP/1.1 302 Found
  Location: http...#access_token=XXX&state=YYY&token_type=Bearer&expires_in=3600

-Implicit Flowを利用している場合、Authorization Code Flowを利用できないか確認する。
-AuthorizationServerが[[Access Token>#jb722a87]]が発行された対象のClientを確認できるAPIを提供する。~
これにより、[[Access Token>#jb722a87]]置き換え攻撃を検知できる(RFCに定義はないので独自実装する)。
-OpenID ConnectのID Tokenを利用する。
--失敗レスポンス例
  HTTP/1.1 302 Found
  Location: http...#error=access_denied&state=YYY

**参考 [#bc772000]
***[[Tokenエンドポイント>#s820b1ab]] [#n037bd41]

***OAuth 2.0 and the Road to Hell [#y1f5c2c5]
-OAuth 1.0 のほうが OAuth 2.0 より安全なの? - Qiita~
http://qiita.com/TakahikoKawasaki/items/3600b28af7b63671b968
--「OAuth 2.0 は OAuth 1.0 よりも安全ではない」とは言えない。
--OAuth 1.0 でClientを作る方こそ安全ではない。
--OAuth 1.0 ではなく OAuth 2.0 を採用するのが良い。
-リクエスト例
--authorization_code
  POST /token HTTP/1.1
  Host: ...
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded
  
  grant_type=authorization_code&code=XXXX&redirect_uri=http...

***Inspecting access tokens [#sace68e4]
-OAuth2.0の備忘録的まとめ - Ari-Press~
http://www.ari-hiro.com/blog/2012/12/30/oauth2-summary
--Manually Build a Login Flow - Facebook Login~
https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow/v2.4
--refresh_token
  POST /token HTTP/1.1
  Host: server.example.com
  Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
  Content-Type: application/x-www-form-urlencoded
  
  grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA

-レスポンス例
--成功
  HTTP/1.1 200 OK
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache
  
  {
    "access_token":"XXX",
    "token_type":"Bearer",
    "expires_in":3600,
    "refresh_token":"YYY",
    "example_parameter":"ZZZ"
  }

--失敗
  HTTP/1.1 400 Bad Request
  Content-Type: application/json;charset=UTF-8
  Cache-Control: no-store
  Pragma: no-cache
 
  {
    "error":"invalid_request"
  }

*The OAuth 2.0 Authorization Framework [#v698197b]
-RFC 6749 - The OAuth 2.0 Authorization Framework~
https://tools.ietf.org/html/rfc6749

-OAuth 2.0 Core & Bearer Spec (RFC 6749 & RFC 6750) 翻訳公開! - OAuth.jp~
http://oauth.jp/blog/2013/01/23/oauth-20-core-bearer-spec-rfc-rfc-6749-rfc-67/
--The OAuth 2.0 Authorization Framework~
http://openid-foundation-japan.github.io/rfc6749.ja.html
--The OAuth 2.0 Authorization Framework: Bearer Token Usage(日本語)~
http://openid-foundation-japan.github.io/rfc6750.ja.html

**(RFC 6749) OAuth 2.0のフロー定義 [#kd90c6bf]
**RFC 6749 - OAuth 2.0のフロー定義 [#kd90c6bf]
OAuth 2.0仕様には4つのフローが定義されている。~
これらのフローのタイプを「グラント種別」と呼ばれる。

-IPA ISEC セキュア・プログラミング講座:~
Webアプリケーション編 第8章 マッシュアップ:サーバサイドマッシュアップ~
https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html

以下の様な「グラント種別」がある模様。

***Authorization Codeグラント種別 [#y8bf613e]
-RFC 6749 - The OAuth 2.0 Authorization Framework~
4.1.  Authorization Code Grant~
-RFC 6749 - The OAuth 2.0 Authorization Framework > 4.1.  Authorization Code Grant~
https://tools.ietf.org/html/rfc6749#section-4.1

--Authorization Code Flow
 +----------+
 | Resource |
 |   Owner  |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier      +---------------+
 |         -+----(A)-- & Redirection URI ---->|               |
 |  User-   |                                 | Authorization |
 |  Agent  -+----(B)-- User authenticates --->|     Server    |
 |          |                                 |               |
 |         -+----(C)-- Authorization Code ---<|               |
 +-|----|---+                                 +---------------+
   |    |                                         ^      v
  (A)  (C)                                        |      |
   |    |                                         |      |
   ^    v                                         |      |
 +---------+                                      |      |
 |         |>---(D)-- Authorization Code ---------'      |
 |  Client |          & Redirection URI                  |
 |         |                                             |
 |         |<---(E)----- Access Token -------------------'
 +---------+       (w/ Optional Refresh Token)

Note: The lines illustrating steps (A), (B), and (C) are broken into two parts as they pass through the user-agent.

***Implicitグラント種別 [#h347a7c6]
-RFC 6749 - The OAuth 2.0 Authorization Framework~
4.2.  Implicit Grant~
-RFC 6749 - The OAuth 2.0 Authorization Framework > 4.2.  Implicit Grant~
https://tools.ietf.org/html/rfc6749#section-4.2

--Implicit Grant Flow
 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      ^
      |
     (B)
 +----|-----+          Client Identifier     +---------------+
 |         -+----(A)-- & Redirection URI --->|               |
 |  User-   |                                | Authorization |
 |  Agent  -|----(B)-- User authenticates -->|     Server    |
 |          |                                |               |
 |          |<---(C)--- Redirection URI ----<|               |
 |          |          with Access Token     +---------------+
 |          |            in Fragment
 |          |                                +---------------+
 |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
 |          |          without Fragment      |     Client    |
 |          |                                |    Resource   |
 |     (F)  |<---(E)------- Script ---------<|               |
 |          |                                +---------------+
 +-|--------+
   |    |
  (A)  (G) Access Token
   |    |
   ^    v
 +---------+
 |         |
 |  Client |
 |         |
 +---------+

Note: The lines illustrating steps (A) and (B) are broken into two parts as they pass through the user-agent.

***Resource Owner Password Credentialsグラント種別 [#i2483bc0]
-RFC 6749 - The OAuth 2.0 Authorization Framework~
4.3.  Resource Owner Password Credentials Grant~
-RFC 6749 - The OAuth 2.0 Authorization Framework > 4.3.  Resource Owner Password Credentials Grant~
https://tools.ietf.org/html/rfc6749#section-4.3

--Resource Owner Password Credentials Flow
 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
 +---------+                                  +---------------+
 |         |>--(B)---- Resource Owner ------->|               |
 |         |         Password Credentials     | Authorization |
 | Client  |                                  |     Server    |
 |         |<--(C)---- Access Token ---------<|               |
 |         |    (w/ Optional Refresh Token)   |               |
 +---------+                                  +---------------+

-参考
--memo: Force.com : REST API 開発 ユーザ名パスワード OAuth 認証~
http://vaindespair.blogspot.jp/2013/01/blog-post_5252.html
---Understanding the Username-Password OAuth Authentication Flow~
Force.com REST API Developer Guide | Salesforce Developers~
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_understanding_username_password_oauth_flow.htm

***Client Credentialsグラント種別 [#ka6e3a8f]
-RFC 6749 - The OAuth 2.0 Authorization Framework~
4.3.  Resource Owner Password Credentials Grant~
-RFC 6749 - The OAuth 2.0 Authorization Framework > 4.3.  Resource Owner Password Credentials Grant~
https://tools.ietf.org/html/rfc6749#section-4.4

--Client Credentials Grant
 +---------+                                  +---------------+
 |         |                                  |               |
 |         |>--(A)- Client Authentication --->| Authorization |
 | Client  |                                  |     Server    |
 |         |<--(B)---- Access Token ---------<|               |
 |         |                                  |               |
 +---------+                                  +---------------+

**RFC 6750 - [[Bearer Token>#i5f79713]] Usage [#d65223fc]
-RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage~
https://tools.ietf.org/html/rfc6750

***概要 [#z2e4e62c]
-認可サーバーにより発行されたAccessトークンを、~
保護リソースエンドポイント (狭義の Web API) に渡す方法を定めた仕様

-次の 3 つの方法を定義されている。
--[[Authorization Request Header Field>https://tools.ietf.org/html/rfc6750#section-2.1]]~
Authorization ヘッダに埋め込む方法
--[[Form-Encoded Body Parameter>https://tools.ietf.org/html/rfc6750#section-2.2]]~
リクエスト・ボディに埋め込む方法
--[[URI Query Parameter>https://tools.ietf.org/html/rfc6750#section-2.3]]~
クエリ・パラメタとして渡す方法

***フロー [#xf758bc1]
  +--------+                               +---------------+
  |        |--(A)- Authorization Request ->|   Resource    |
  |        |                               |     Owner     |
  |        |<-(B)-- Authorization Grant ---|               |
  |        |                               +---------------+
  |        |
  |        |                               +---------------+
  |        |--(C)-- Authorization Grant -->| Authorization |
  | Client |                               |     Server    |
  |        |<-(D)----- Access Token -------|               |
  |        |                               +---------------+
  |        |
  |        |                               +---------------+
  |        |--(E)----- Access Token ------>|    Resource   |
  |        |                               |     Server    |
  |        |<-(F)--- Protected Resource ---|               |
  +--------+                               +---------------+

*その他 [#e8ba8e4e]

**[[OAuth 2.0 拡張]] [#s986286e]

**[[OAuth 2.0 セキュリティ関連トピック]] [#o1f40fef]

*参考 [#sd7d7875]
-OAuth - Wikipedia~
https://ja.wikipedia.org/wiki/OAuth

**OAuth 1.0 [#b6b38b34]

-OAuth Core 1.0~
http://oauth.net/core/1.0/

-ゼロから学ぶOAuth:特集|gihyo.jp … 技術評論社~
http://gihyo.jp/dev/feature/01/oauth
--第1回 OAuthとは?―OAuthの概念とOAuthでできること~
http://gihyo.jp/dev/feature/01/oauth/0001
--第2回 OAuth Consumerの実装(入門 : OAuth Access Tokenの取得と利用)~
http://gihyo.jp/dev/feature/01/oauth/0002
--第3回 OAuth Consumerの実装(応用 : smart.fm APIおよびGoogle Data APIsの利用)~
http://gihyo.jp/dev/feature/01/oauth/0003
--第4回 OAuth Service Providerの実装~
http://gihyo.jp/dev/feature/01/oauth/0004

**OAuth 2.0 [#q09835d5]
-[[The OAuth 2.0 Authorization Framework>#v698197b]]

-今更聞けないOAuth2.0~
http://www.slideshare.net/ph1ph2sa25/oauth20-46144252

-OAuth 2.0 の仕組みと認証方法 | murashun.jp~
https://murashun.jp/blog/20150920-01.html

-OAuth 2.0 の仕様を読むために - Qiita~
http://qiita.com/awakia/items/66975de18ba25f18a961
-OAuth 2.0の代表的な利用パターンを仕様から理解しよう - Build Insider~
http://www.buildinsider.net/enterprise/openid/oauth20

-デジタル・アイデンティティ技術最新動向 連載インデックス - @IT~
***@IT [#n0d6d892]
-デジタル・アイデンティティ技術最新動向 連載インデックス~
http://www.atmarkit.co.jp/fsecurity/index/index_digid.html
--デジタル・アイデンティティ技術最新動向(1):「OAuth」の基本動作を知る - @IT
--デジタル・アイデンティティ技術最新動向(1):「OAuth」の基本動作を知る
---http://www.atmarkit.co.jp/ait/articles/1208/27/news129.html
---http://www.atmarkit.co.jp/ait/articles/1208/27/news129_2.html

-OAuth 2.0でWebサービスの利用方法はどう変わるか - @IT
-OAuth 2.0でWebサービスの利用方法はどう変わるか
--http://www.atmarkit.co.jp/fsmart/articles/oauth2/01.html
--http://www.atmarkit.co.jp/fsmart/articles/oauth2/02.html
--http://www.atmarkit.co.jp/fsmart/articles/oauth2/03.html

-色々な OAuth のフローと doorkeeper gem での実装 - Qiita~
***Qiita [#rde475d1]
-OAuth 2.0 の仕様を読むために~
http://qiita.com/awakia/items/66975de18ba25f18a961
-色々な OAuth のフローと doorkeeper gem での実装~
http://qiita.com/tyamagu2/items/5aafff7f6ae0a9ec94aa
-OAuth 2.0 全フローの図解と動画~
https://qiita.com/TakahikoKawasaki/items/200951e5b5929f840a1f
-IETF OAuth WGの仕様全部見る~
https://qiita.com/ritou/items/bbf7ffd001f30ec6facc

-OpenID Connect 入門 〜コンシューマーにおけるID連携のトレンド〜~
***slideshare [#o0d0ea56]
-今更聞けないOAuth2.0~
http://www.slideshare.net/ph1ph2sa25/oauth20-46144252

-OpenID Connect 入門~
〜コンシューマーにおけるID連携のトレンド〜~
OAuth 2.0 Authorization Code Flow~
http://www.slideshare.net/kura_lab/openid-connect-id/21

**ritou [#p1bd361f]

***r-weblife [#ied09bc5]
-Authlete の OAuth 2.0 / OIDC 実装ナレッジ 完全に理解した~
https://ritou.hatenablog.com/entry/2018/10/02/013902
-ファーストパーティーなアプリが使うOAuth/OIDCについてのお話 2019 春~
https://ritou.hatenablog.com/entry/2019/03/03/023431

**テストサイトなど [#gf957f66]
-OAuth 2.0 Playground~
https://www.oauth.com/playground/

-OAuth 2.0 debugger~
https://oauthdebugger.com/

-OpenID Connect debugger~
https://oidcdebugger.com/

-Documentation | Okta Developer~
https://developer.okta.com/documentation/

**内部リンク [#rc0cd72f]

***[[技術文書中での Shall / Should / May]] [#gb7e1f1d]

***[[Microsoft Azure Active Directory]] [#f331a146]

----
Tags: [[:IT国際標準]], [[:認証基盤]], [[:クレームベース認証]], [[:OAuth]]


トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS