ユーザー認証の手抜き

Webアプリ作っているといろんな局面でユーザー認証が必要になる局面がある。まじめにつくると果てしなく面倒だし、適当につくるとセキュリティ上問題になるので、要件に応じて適切に手抜きする必要がある。

適当なやつからしっかりしたやつまでなんとなくソートしていくとこんなかんじだと思う。

認証なし
IPで弾く
Basic認証（ソースコード、設定ファイルにパスワードベタ書き）
Basic認証（DBにUserテーブルをつくってパスワードを保存。追加はcliとかで手動）
login/logout画面作成。cookieなりmemcacheなりにセッションを保存
webからユーザーを追加できるように
password変更機能
OAuth
OpenID
mailを送ってリンクをクリックさせてメールアドレスの所有確認
メールアドレス変更機能
メールを使ってのパスワードリセット機能
OAuthで作ったアプリへの後からのメールアドレスとパスワード追加登録機能
二段階認証

不特定多数のユーザーが登録する場合に開発として楽なのはid/password方式。
メールアドレス認証とかがない純粋なidだとすごい楽です。
こういうときOAuth選びがちだけど意外と使い勝手悪い。

OAuth使うと発生する問題

ライブラリの依存とか諸々ではまりやすい
OAuth provider (TwitterとかFBとかギッハブとか）に依存することになる
複数のOAuth providerに対応すると1人のユーザーが複数アカウント重複してしまう可能性がでてきてめんどくさくなる
Native Appつくるときに認証でWebView開いて(myapp(web) -> Twitter -> myapp(web) -> myapp(native))みたいなcallbackの嵐をやるハメになる
Native Appのバイナリ内にサーバー側と同じConsumer Key/Consumer Secretを持つとセキュリティ上問題があるのでNativeでは持たないようにするなり、別のConsumer Keyを持つなりしないといけない
更にマジメな話をするとアプリ内WebViewで外部サービスのパスワード入力させて認証させるのはfishingのおそれがあるのでアドレスバーが信頼できる外部ブラウザアプリに飛ばして認証させたほうが良い

追記

OAuthは認可であって認証ではないうんぬんの話は承知しておりますが現実としてその辺に詳しくないエンジニアの皆様は「Twitterで認証」とおっしゃられてますし、TwitterにOAuthで認可を得てverify_credential.jsonを叩いた結果からuser_idを取得するとそれは認証として問題なく使えてしまうという現実もあります（余計な権限の認可もついていますが、そっちもなんだかんだで使うし）。OAuth単独だと認証機能がないというのは事実なんですが一般的に言うOAuthとは要するにTwitterでありFacebookでありそれらのAPIと組み合わせることで認証機能を得ることができるし、IDな人たちが大好きなOpenIDの最新規格であるOpenID ConnectだってOAuthでaccess_token取得するついでにIdentityもついてくるというTwitter APIのverify_credentialを呼ぶ手間が省けて共通規格にしましたみたいなもんだし、日曜深夜にこんな長文書くハメになるのでOAuthがどうとか認証とか認可とかの議論やめたい。