リッチクライアントの認証はどうすべきか・・・
多くのアプリケーションはユーザー認証をしないと使えない場合が多い。今作っているアプリケーションもまさにそれだ。
しかし，アプリケーション開発者としては，ユーザー認証の問題は厄介だ。
1. ユーザーは新しいアカウントを作りたがらない
2. ユーザーアカウントを作成，管理するシステムを作るのはクソ面白くなく，面倒
3. そもそも問題を引き起こしかねないパスワードを収集したくない
そこで導入を検討するのがOAuth（オース）やOpenIDということになるだろう。
しかし，通常のHTMLベースのWEBアプリケーションなら問題はないかもしれないが，Flex, AIR, iPhoneなどリッチクライアント技術を使ったアプリケーションでは致命的な問題があることがわかった。
それは認証時にサイトを一度中断して離れざるを得ない事だ。そのプロセスはこうだ。
1. ユーザーがサイト（コンシューマ，つまりアプリケーション提供者のサイト）に行く
2. ログインボタンを押す
3. サービスプロバイダ（ID,パスワードを管理しているサイト）に移動する（アプリケーションを中断して）
4. ユーザーがIDとパスワードを入力する
5. 認証できれば自動的に元のサイトにリダイレクトで戻される
ユーザーがパスワードをコンシューマに渡さなくても済むように，という根本的な目的があるのでこういう仕組みであるのは理解できる。しかしこれでは・・・
Flexならブラウザ上で動くので，これでもなんとか認証できなくもない。しかしブラウザから独立したAIRやiPhoneアプリの場合はどうすんの？リダイレクトったって，ブラウザ上で動作してないわけだから無理ポ。
しかし，ここでも抜け道がないわけではないようだ。AIRでもiPhoneでもアプリ内でブラウザを開く事ができるので，これを使うと何とか認証できるようだ。
「OAuth on the iPhone」
「OpenID From AIR（Google上のキャッシュ）」
しかし・・・AIRの記事の筆者が言うように，これでは「wacky work-a-rounds」（変チクリンな回避策）と言わざるを得ない。
ということで，どうやらOpenIDもOAuthもリッチクライアントでの認証にはうまく使えそうにないが，wackyなワークアラウンドで何とか頑張るのか？何かもっと良い方法は無いのか？
頑張らないとすればどうするのか？やはり独自にユーザー認証システムを作るしかないのか？
よくよく考えると，Twitterのブレイン・クックさんらはOpenIDの限界を感じてOAuthを作ったそうだが，TwitterのログインページやサインナップページにOpenIDの「O」の字，OAuthの「O」の字があるか？といえば無いわけで・・・ということは，独自実装だろう。
ふむぅ。考えどころだ・・・o(￣ー￣;)ゞ
しかし，OpenIDもOAuthも仕組みが複雑すぎないか？開発者でもすぐには理解できないような仕組みをユーザーが理解できるのか？そんな説明を受ける前に，とっとと新しいIDを作った方が，他のサービスに影響もなく安全で早いということにならないか？
ぐぉぉぉ(〒＿〒)
しかし，アプリケーション開発者としては，ユーザー認証の問題は厄介だ。
1. ユーザーは新しいアカウントを作りたがらない
2. ユーザーアカウントを作成，管理するシステムを作るのはクソ面白くなく，面倒
3. そもそも問題を引き起こしかねないパスワードを収集したくない
そこで導入を検討するのがOAuth（オース）やOpenIDということになるだろう。
しかし，通常のHTMLベースのWEBアプリケーションなら問題はないかもしれないが，Flex, AIR, iPhoneなどリッチクライアント技術を使ったアプリケーションでは致命的な問題があることがわかった。
それは認証時にサイトを一度中断して離れざるを得ない事だ。そのプロセスはこうだ。
1. ユーザーがサイト（コンシューマ，つまりアプリケーション提供者のサイト）に行く
2. ログインボタンを押す
3. サービスプロバイダ（ID,パスワードを管理しているサイト）に移動する（アプリケーションを中断して）
4. ユーザーがIDとパスワードを入力する
5. 認証できれば自動的に元のサイトにリダイレクトで戻される
ユーザーがパスワードをコンシューマに渡さなくても済むように，という根本的な目的があるのでこういう仕組みであるのは理解できる。しかしこれでは・・・
Flexならブラウザ上で動くので，これでもなんとか認証できなくもない。しかしブラウザから独立したAIRやiPhoneアプリの場合はどうすんの？リダイレクトったって，ブラウザ上で動作してないわけだから無理ポ。
しかし，ここでも抜け道がないわけではないようだ。AIRでもiPhoneでもアプリ内でブラウザを開く事ができるので，これを使うと何とか認証できるようだ。
「OAuth on the iPhone」
・・・The naive solution is simple. The iPhone SDK provides a UIWebView control that lets applications integrate a web page with their UI. Instead of launching Safari, a Consumer could use a UIWebView to integrate the authorization page with the rest of their application. ・・・
「OpenID From AIR（Google上のキャッシュ）」
・・・In the AIR app I can just use the HTML component and point it towards the login form of the web services. The user can then log in using either username/password or OpenID just like they do on the website. Now, here’s the cool part… The AIR HTML component shares a network stack with the AIR/Flex NetConnection object. That means any session/cookies/whatever opened in the HTML component carry through to the remoting calls I want to make from Actionscript.・・・
しかし・・・AIRの記事の筆者が言うように，これでは「wacky work-a-rounds」（変チクリンな回避策）と言わざるを得ない。
ということで，どうやらOpenIDもOAuthもリッチクライアントでの認証にはうまく使えそうにないが，wackyなワークアラウンドで何とか頑張るのか？何かもっと良い方法は無いのか？
頑張らないとすればどうするのか？やはり独自にユーザー認証システムを作るしかないのか？
よくよく考えると，Twitterのブレイン・クックさんらはOpenIDの限界を感じてOAuthを作ったそうだが，TwitterのログインページやサインナップページにOpenIDの「O」の字，OAuthの「O」の字があるか？といえば無いわけで・・・ということは，独自実装だろう。
ふむぅ。考えどころだ・・・o(￣ー￣;)ゞ
しかし，OpenIDもOAuthも仕組みが複雑すぎないか？開発者でもすぐには理解できないような仕組みをユーザーが理解できるのか？そんな説明を受ける前に，とっとと新しいIDを作った方が，他のサービスに影響もなく安全で早いということにならないか？
ぐぉぉぉ(〒＿〒)
コメント
コメントを投稿