Commits

hideki nara committed 864f275

リクエストオブジェクトにも触れてみるなど

  • Participants
  • Parent commits faa053c

Comments (0)

Files changed (2)

File source/index.rst

 django-social-authでOAuthに触れてみる
 ===============================================
 
+.. note::
+    - `2012 Pythonアドベントカレンダー(Webフレームワーク) <http://connpass.com/event/1439/>`_ の #17 の記事になります
+    - `+hdknr <https://plus.google.com/u/3/111834161848985316983/posts>`_ が書きました。
+    - @yamionp さんからリレーされているはずです。次は @aodag さんにリレーされる予定です。
+
 はじめに
 ==============================================
 
 
 - django-social-authをつかって、Github, Facebook, Twitterなどいろいろアクセスしたり、
   ソースコード読むとソーシャルユーザーの識別子の扱いがまちまちである事に気がつくでしょう。
+  (そもそもソーシャルサイトごとに別のバックエンドが必要です)
 - OAuth2 ではユーザーのアイデンティティを標準的にやり取りすることをスペックでは定めていません。
 - OpenID Connectは(主に)OAuth2の一連のリクエストのやり取りの結果、  :term:`ID Token` という標準化されたデータで
   ソーシャルユーザーのアイデンティティを安全に識別する仕組みを提供しています。
 - アイデンティティ証書や属性を暗号化して渡したり、その情報に :term:`非否認性` をもたせたりするために :term:`JSON Web Token` というデータのシリアライズを標準的に行う仕組みがあります。これは :term:`JOSE` ワーキンググループでディスカッションされている JWK,JWS,JWEに基づいています。
 - 自サービスに訪れたユーザーが自分のソーシャルアイデンティティの認証元を指定し、そのソーシャルサイトとの間で動的に関係をとれる仕組みが用意されています( :term:`Discovery` + :term:`Dynamic Registration` 。 Dynamic Registrationに関しては OAuth2も別のRFC化に向けてディスカッション中です )。 
 - 共有されたアイデンティティ証書(:term:`ID Token`)を元に3者間でセッション管理出来る仕組みがあります( :term:`Session Management` )
+- 認証をどのように行うか、その結果のデータの関して認証コンテキストを拡張する要求を行えるようになっています
+  ( :term:`リクエストオブジェクト` )。
 - リソースがさらに第4者にある場合の考慮もされています
   ( UserInfo : :term:`Aggregated and Distributed Claims` 。OAuth2を基にした :term:`UMA` と言う手順も議論されています)   
  

File source/res.rst

 
     バックエンドコントリビューション
         - http://django-social-auth.readthedocs.org/en/latest/backends/index.html
+
+    Request Object
+    OpenID Request Object
+    リクエストオブジェクト
+        - http://openid.net/specs/openid-connect-messages-1_0.html#OpenID_Request_Object