月: 2009年10月

OAuth

OAuth(オース)ってなんだべ(´・ω・`)?

OAuth は、ブレイン・クックとクリス・メッシーナが始めたオープンプロトコルであり、デスクトップ、モバイル、WebアプリケーションなどにセキュアなAPI認可 (authorization) の標準的手段を提供する。(OAuth

んー、よくわからない(´・ω・`)
余計なところを端折っていくと「セキュアなAPI認可の標準的手段を提供する仕組み」…?
まだあれか。secureが「安全な, 危険のない 」だから「安全なAPI認可をする仕組み」かな?


API認可ってなんだべ(´・ω・`)?
ってぐぐってみたがこれズバリのヒットは見当たらなかった。
OAuthを解説してるページによれば

OAuthは,以下の特徴を持つ「認可情報の委譲」のための仕様です。
・あらかじめ信頼関係を構築したサービス間で
・ユーザの同意のもとに
・セキュアにユーザの権限を受け渡しする(ゼロから学ぶOAuth

そもそもOpenIDはIDの持ち主が本人か確認する「認証(Authentication)」情報をやりとりするためのプロトコルであり、OpenIDプロバイダで認証されたIDがどのリソースにアクセスできるかといった「認可(Authorization)」情報については一切関与しない。(APIアクセス権を委譲するプロトコル、OAuthを知る

認証(Authentication)
そのユーザーが自分の物であると主張するIDに対して、そのIDが確かにそのユーザーの物であるということを保証すること
認可(Authorize)
認証されたIDを受け入れ、サービスに対して適切な権限を与えること
(第1回 仕様から学ぶOpenIDのキホン)

とあった。API認可=APIへのアクセス権の認可ということか。
全然違うけど、OpenIDは入場券でOAuthの方は乗り物券みたいだ(・∀・)


解説ページを読み進めるとこの仕組みは、

OAuthには,大きく分けて3つの登場人物がいます。1つ目はOAuth Service Provider(以下Service Provider)と呼ばれる,ユーザの認可情報を第三者に渡すサービス。2つ目はOAuth Consumer(以下Consumer)と呼ばれる,Service Providerから認可情報を受け取り,ユーザに代っていろいろな情報にアクセスしたり変更/追加を行ったりするサービス。3つめが,Userです。UserはService ProviderがConsumerに認可情報を渡すことを許可したり,すでに受け渡した認可情報を無効にするといったことができます。(ゼロから学ぶOAuth

とある。
Service Providerが「ユーザの認可情報を第三者に渡すサービス」というと何か混乱してくる。
他のサービスを提供せず、"認可情報を第三者に渡す"部分のみに特化して独立的に存在
するのだろうか。
それともあるサービスを提供していてそれと付随または一体化して存在しているのだろうか。
ちょっとわからないけれど実装によるということなんだろうか。


まあ「ユーザーが利用している複数のサービス間で、利用対象サービスのAPIを
他のサービスから安全かつ簡単に利用できるようにするための仕組み
」みたいな感じで
覚えておけばいいかなぁ…(・∀・) 「ユーザーの同意のもと」とか、「サービスプロバイダと
コンシューマの間で事前に信頼関係を構築」というのも厳密には必要なんだろうけれど。
特に自分でOAuth対応プログラムを組まない限りはリクエストトークンとかアクセストークンやら
その辺のことはそんな感じで実現してる程度の知識でいいかな。


でもこれって認可するAPIの設定が甘々だといずれ大変なことになる
んじゃないんだろうか(´・ω・`) 今のところはスパムくらいだけれども…
「OAuth」とは 日本のユーザー襲った“Twitterスパム”の正体 (1/2)
これはどうなんだろうか((((;゚Д゚)))ガクガクブルブル
twitter の OAuth で思ったより豪快に認可してしまっている件