このページではTwitterにおけるオース認証の流れを簡単に説明します。
リンク先のページを参照してください。
ユーザー認証
Twitterに限りませんが、登録したユーザーのみが利用できるWebサービスは
基本的に利用時にユーザー認証を行います。
ユーザー認証(user authentication)とはユーザー名とパスワード等を提示させることによって、
そのユーザー本人であることをシステム側から確認することです。認証を受けたユーザーは
許可されているシステムのサービスへアクセスできます。
※尚、ユーザー側からみるとそのサービスにログインすることなので、このサイトでは
authenticated user,authenticating userをログインしたユーザーと訳しています。
上記のようにOAuth認証では、Service Provider用のPasswordをConsumerに渡さずに、
オース認証は初回のみユーザーネームとパスワードを送信し、幾つかの手順を経た後に
AccessTokenを取得、以降はそのAccessTokenを利用して認証を受けます。
webアプリでこの認証方式を用いるとユーザーのパスワードを預からなくて良いため、
管理の手間やユーザーのパスワード漏洩への不安を幾許か軽減出来ます。
デスクトップクライアントを作る場合は余り大したメリットはありませんが、
こちらもローカルにパスワードを保存せずにすみます。
0.事前にConsumerをService Providerに登録しておきます。
登録を行うとコンシューマーキーとコンシューマーシークレットを取得出来ます。
実際の手順についてはJ.アプリケーションの登録で説明します。
尚、ここでいうConsumerはデスクトップクライアントを想定しています。
1.UserがConsumerを利用します。
(具体的にはクライアントの起動やWebアプリへのアクセスです)
2.ConsumerはAccessTokenを持っている場合は、そのまま認証を
受けますが、持っていない場合はRequestTokenを要求します。
この時、Consumerはコンシューマーキーとコンシューマーシークレットを送信します。
3.Service ProviderはConsumerに対しRequest Tokenを発行します。
(Request TokenはConsumerの情報を含みます)
4.ConsumerはUserをService Providerのページへ誘導します。
この時、Request Tokenを引数としてURLに付加しています。
5.UserはIDとパスワードでService Providerにログインします。
6.Service ProviderはRequest TokenからConsumerの情報を取得し、
Userに対してアクセス権の移譲を許可するか確認を促します。
7.Userが許可します。
※6の許可確認 Consumer : MarubatsuClient / User : elekingmole の場合
8.Service Providerが暗証番号(PIN CODE)を表示します。
9.UserがConsumerに対し暗証番号を渡します（入力）。
10.Consumerが暗証番号とRequest Tokenを使ってService ProviderにAccess Tokenを要求します。
RequestTokenはこれ以降使用しません。
11.Service ProviderがAccess Token(及びAccess Secret)をConsumerに発行します。
このAccess Token(及びAccess Secret)を保存します。
8.暗証番号表示
9.GALAcTTERの場合はpin code を入力後、"了解"ボタンを押すと、10の要求を行います。
12.以降、ConsumerはAccess Token(及びAccess Secret)とConsumer Key,Consumer Secretを
用いて認証を受けます。
UserはPasswordを入力せずにConsumerとService ProviderのServiceを利用出来るようになります。
(これはService Providerの認証を受ける為のPasswordのことでConsumerがWebアプリ等で
Consumerに対してのPasswordを要求する場合はその限りではありませんが)
上記のようにOAuth認証では、Service Provider用のPasswordをConsumerに渡さずに、
Consumerにアクセス権の移譲を行えます。これは非常に便利な仕組みです。
以前、OAuthを利用したスパムがありましたが、これ自体はOAuthの穴というよりも
DirectMessageというある種の信頼関係の虚を突くソーシャルハッキングだったと思います。
OAuth認証に無理に難点を言うならば、
1.いきなりService Providerが開き、ログインするとよくわからない暗証番号が表示されて戸惑う
2.クライアントソフトの場合、解析されるとConsumer KeyとConsumer Secretが盗まれてしまう？
といったところでしょうか。まあ取り立てて致命的な問題ではないと思います。
1.に関してのユーザーの戸惑いを軽減したり、ユーザー操作の負担をなくしたものが、
次に説明するxAuth認証です。
オース認証についての説明は以上です。
