Request Tokenの取得と認証を省略したもので、Webブラウザで認証画面を開く必要はない
“ BASIC認証は実装が簡単な一方で、セキュリティ面で不安がある。Twitter OAuth認証は、外部サービスに対して適切な利用権限を委譲するためにGoogleやTwitterなどが中心となって考案したもの。一見する OAuth認証の仕組みとしては、サービスやアプリケーション（OAuthコンシューマー）がOAuthプロバイダー（ここではTwitter） しかし、OAuth認証はその認証プロセスを見て分かるように、認証画面はOAuthプロバイダー側に遷移する（認証完了後、OAuthコン そこで2010年になって登場したのが、もう1つの認証方式である「xAuth」だ。xAuthはOAuth 丹羽氏も、「xAuthは（OAuthの）例外的な対応というのが正しい見方」としており、特殊な用途に対応するための認証がxAuthであると
APIの利用についていえば、Twitterと連携した外部サービスを利用するために、Twitterのユーザー名とパスワードを第三者に渡してしまうこ
とが特に問題となる。これはつまり、ユーザーがTwitterで行える全権限を第三者に与えてしまっているのに等しい。これを改善するものとして、ユー
ザー名とパスワードとはひも付かないトークンベースで、あらかじめ決められたAPIのアクセスのみを許可しようというのが「OAuth
認証」だ。
とOpenIDに
似ているが、OpenIDがログインや新規登録時の本人確認を外部で担保するためのものであるのに対し、OAuth認証は、外部サービスなどを通じた
APIの利用に対して制限可能な認可をトークンに対して与えるもので、リソースの種類や有効期間などを細かくコントロールできるのが特徴となる。上述した
ように、トークンはユーザー名やパスワードとはひも付いていないので、万が一不正利用された場合でも、そのトークンを個別に破棄すれば被害を最小限に抑え
ることができる。
に接続してRequest Tokenを取得、認証画面を開いてRequest Tokenを承認させ、そのRequest
Tokenを使ってAccess TokenとToken
Secretを取得することで各APIを利用する。OAuthコンシューマーにとっては、クレデンシャル（認証情報）を自前で持たずに済むので、情報セ
キュリティなどの観点からメリットは大きい。TwitterはBASIC認証をサポートしながらも、OAuth認証を利用した場合の3分の1にリミット
レートを制限するなどして、OAuth認証への移行を推奨してきた。今回のBASIC認証廃止は、十分な周知が図られたと判断したためとしている。
シューマーが指定したコールバックURLに遷移）ため、Webブラウザが立ち上がる。例えばiPhoneアプリの開発であれば、WebKitフレームワー
ク「UIWebView」のdelegateでコールバックの呼び出しをみて、そこからトークンを取得するような“行儀の悪い”方法で回避できるかもしれ
ないが、いずれにせよモバイルアプリケーションを含めたデスクトップアプリケーションとの親和性がお世辞にも高いとはいえない認証方式だった。
認証の仕組みからRequest
Tokenの取得と認証を省略したもので、Webブラウザで認証画面を開く必要はない。デスクトップアプリケーションとの親和性が高い認証方式といえる
が、SSLでの接続が必須である点や、利用に関して、事前にTwitterによる審査を受ける必要がある。
いう見解を示している。
— | TwitterのBASIC認証廃止、企業ユーザーが知っておくべきこと - ITmedia エンタープライズ |
