OpenID、OAuth | 気まぐれエンジニアの　セルフ・デザイン＆セルフ・マネジメント
Amebaホームピグアメブロ
芸能人ブログ人気ブログ
新規登録
ログイン

気まぐれエンジニアの　セルフ・デザイン＆セルフ・マネジメント

システムエンジニアをやってます。
ITのこと、デザインのこと、仕事のことなど自分の興味持ったことをまとめていきたいと思っています

OpenID、OAuth

2012年のソーシャルWeb
http://gihyo.jp/dev/column/newyear/2012/socialweb-prospect?page=1

この記事を読んでて、前から気になっていたOpenID、OAuthについて調べてみました。

【OpenID】
webサイトのURL 形式で構成されたユーザーの身元確認をするためのID
OpenIDの最も重要な部分は「認証すること(URLの所有者であることを証明すること) 」
1つのOpenIDを作成するだけで、Open IDに対応する全てのウェブサイトに面倒な情報を入力せずともログインすることができる

SUUMOにおけるOpenID,Oauthの活用について
http://www.openid.or.jp/download/summit_tokyo/A2_Recruit.pdf

第1回 仕様から学ぶOpenIDのキホン
http://www.atmarkit.co.jp/fsecurity/rensai/openid01/openid01.html
ユーザー中心の分散ID認証システム

認証（Authentication）
　　そのユーザーが自分の物であると主張するIDに対して、
　　そのIDが確かにそのユーザーの物であるということを保証すること 

認可（Authorize）
　　認証されたIDを受け入れ、サービスに対して適切な権限を与えること

OpenIDは分散認証システムであり、認証プロバイダが複数存在

１．OpenIDにおけるIDとはURLのことである。 

２．End Userは自分のClaimed IdentifierをConsumerに対して認証してくれるIdPに加入していなければならない。
　　End UserはどのIdPに加入していても良く、 ConsumerはいずれのIdPであっても協調してEnd UserのClaimed Identifierの認証手続きを行わなければならない。

３．IdPがConsumerに対して認証するのはEnd UserのClaimed Identifier、即ちURLが、End Userが確かに所有しているかどうかということである。


第5回 OpenID Authentication 2.0時代の幕開け
OpenID 2.0の仕様の日本語訳

　XRIのシンタックスはURIの拡張
　@：組織や団体、企業などを表す
　=：個人を表す
　　例を挙げるなら、
　　xri://@itmedia
　　xri://=zigorou

　「xri://=zigorou」であれば、「xri://」を省略して、
　http://xri.net/=zigorou?_xrd_r=application/xrds+xml
　のようなhttp（s）のリクエストを送れば、XRDS文書が返ってくる

　「XRDS文書」・・・そのXRIに対してどのようなサービスが利用可能かを表すXML文書

OpenIDとXRI――XRIが生まれた背景からXRIを知る
　XRIとは
　　・リソースの所在を表す語彙（ごい）が豊富な識別子である
　　・汎用的であり、構造化されたデータや、関連性を表現できる
　　・インターネット上において問い合わせを行うことができる仕組みである
　　・URIとIRIに対して互換性がある

　　XRI・・・eXtensible Resource Identifierの略
　　URIとIRIと互換性がある、ユーザーのリソースを指し示すための識別子。
　　特定の通信レイヤーに依存しない、語彙の拡張されたもの。
　　抽象的な文字列の識別子で名前解決を行うプロトコル。

OpenIDが熱狂的に受け入れられる理由
ちょっと前に話題になったOpenID Connectの仕様とは？
http://d.hatena.ne.jp/ritou/20100919/1284822456
　・OAuth 2.0を使って、URL形式のUser Identifierを返す
　・User Identifierは User Info APIとして属性情報取得に利用できる
　・host-metaを利用した独自Discoveryと、DynamicにClient登録のしくみがある


　近年急速に広まったOAuthは、OpenIDでは出来なかったサービス認可を
　可能にするものとして作られた。
　OpenID Connectは、そのOAuthの後継OAuth 2.0をベースとして
　仕様策定が進められており、OAuth 2.0の拡張性を生かし、
　OAuthのサービス認可に加えて、OpenIDのID連携機能を強化した仕様となっている。


【OAuth】
あらかじめ信頼関係を構築したサービス間でユーザの同意のもとに
セキュアにユーザの権限を受け渡しする「認可情報の委譲」のための仕様
最近ではGoogle，Yahoo!，TwitterなどのAPIでも独自認証やBasic認証と
併用する形でOAuthのサポートが広がっています。
Request TokenとAccess TokenというTokenベースの認可情報をやりとりする

0.ConsumerはService ProviderからあらかじめOAuth利用許可を得る
1.UserがConsumerに，Service Providerから認可が必要な情報への
　アクセス権を取得するように指示する。
2.ConsumerはバックグラウンドでService Providerにアクセスし，
　未認可のRequest Tokenを取得する
3.ConsumerはUserをService Providerにリダイレクトさせる。
　この際Consumerは未認可のRequest TokenをURL Parameterに付加する
4.UserはService Provider上でConsumerへのアクセス権委譲を許可する。
　この際Service Providerは未認可のRequest Tokenを認可済とする
5.Service ProviderはUserをConsumerにリダイレクトさせる。
　この際Service Providerは認可済のRequest TokenをURLに含める
6.ConsumerはバックグラウンドでService Providerと通信を行い，
　認可済のRequest Tokenを実際のアクセス権を示すAccess Tokenと交換する
7.Consumerは6)で得られたTokenを利用して，特定の情報にアクセスする


APIアクセス権を委譲するプロトコル、OAuthを知る
http://www.atmarkit.co.jp/fsecurity/special/106oauth/oauth01.html
OAuthの開発は、2006年末にTwitterのブレイン・クック氏が同社で開発する
API認証をOpenIDで行おうと試行錯誤していたことに端を発する。
OpenIDではTwitterのAPIアクセス権を別のアプリケーションに
委譲（Delegation）することはできないと判断した
そもそもOpenIDはIDの持ち主が本人か確認する「認証（Authentication）」情報を
やりとりするためのプロトコルであり、OpenIDプロバイダで認証されたIDが
どのリソースにアクセスできるかといった「認可（Authorization）」情報については
一切関与しない。
この問題の解決に取り組むべくThe OAuth Google Groupを立ち上げ、
グループを通じて意見を交換しながらAPI認可プロトコルの標準仕様の策定を開始

OAuthプロトコルの特徴は、
１．APIの接続確認にトークンを使うこと
２．そのトークンはユーザーの同意に基づいてサービスプロバイダからコンシューマへ付与されること

OAuth 2.0でWebサービスの利用方法はどう変わるか
http://www.atmarkit.co.jp/fsmart/articles/oauth2/01.html
　OAuthの持つ2つの特徴
　１．パスワードをサードパーティのアプリに渡すことなくAPIを利用できる
　２．どのリソースにアクセス可能かを細かくユーザーに認可させることができる

　 OAuth 1.0の3つの課題
　１．署名と複雑な認証フロー
　２．OAuth 1.0はWebアプリのみを対象としていて、モバイルやデスクトップアプリでは、
　　　OAuth 1.0の仕組みはあまりうまくいっていない
　３．リクエストトークンはよく使用されずに捨てられることが多いが、
　　　サービスプロバイダはリクエストトークンを保持する必要があった。
　　　リクエストトークンを長い期間保持するのはセキュリティも低下し、管理も大変になる

　OAuth 2.0の大きな特徴は3つ
　　１．HTTPSを必須にし、署名をなくし、トークン取得も簡略化
　　２．アクセストークンのみでリソース取得が可能に
　　３．Webアプリも含め、4つのクライアントプロファイルを仕様化
①Webサーバ（Web Server）
　 　　従来のようにクライアントがWebアプリケーションの場合。
　　　　　　FacebookのGraph API、mixi Graph APIは、この仕様にのっとっています。
②ユーザーエージェント（User-Agent）
　 　　JavaScriptのように、OAuthクライアントがWebブラウザ上で動いている場合の仕様。　　　　　　FacebookのGraph APIとTwitter @Anywhereが、このフローに対応。
③ネイティブアプリ（Native Application）
　　　 　　モバイルやデスクトップアプリのための仕様。ガイドラインの定義のみ
　　　　④自立クライアント（Autonomous）
　　既存の認証フレームワークとSAMLなどのプロトコルを使って連携する場合のフロー

OAuth 2.0の仕様の日本語訳