【技術メモ】API認証周り
API認証周り
今回の話は、つまるところこのサイトで大体完結する。
HTTPSとHTTP
HTTPのしくみに、通信相手の認証と、通信の暗号化を載せたもの
あくまでも通信相手と通信自体の保護
┌─┐ ┌─┐ │ │ HTTPS Request (via DNS) │ │ │ │----------------------------------------->│ │ │ │ │ │ │ │ TCP/IP 3way-Hand-Shake │ │ │ │<---------------------------------------->│ │ │ │ │ │ │ │ Send SSLServerCertificate and Pub-Key │ │ │ │<-----------------------------------------│ │ │ │ │ │ │B│---┐Contact the CA │S│ ←通信相手の認証 │r│<--┘ │e│ │o│ │r│ │w│ Encrypt with Pub-Key and send Common-Key │v│ │s│----------------------------------------->│e│ │e│ │r│ │r│ Secure connection using Common-key │ │ ←通信の暗号化 │ │<---------------------------------------->│ │ └─┘ └─┘
パスワード、メールでの認証の一般的なやり方と認証後のやりとり
Web Application
- （HTTPSであることを前提に、）
- シンプルなサーバサイドWebアプリの場合、ID/パスワードでサーバ側で本人確認をして、
- セッションを開始、セッションIDをCookieにセットしてクライアントに返して、
- 認証後はCookieに入れたセッションIDを利用して本人確認を行う
Cookie のsecure属性とHttpOnly属性の設定は必須
認証方式という文脈では、一応もっと簡潔に、BASIC認証で済ませることも可能
- Webサーバでパスワード認証をかけて、認証しないとコンテンツにアクセスできなくする
- 盗聴・改竄が可能なので、まじめに認証する場合に使うものではない
- 試験環境のサイトでとりあえずかけといたりする
Web API
www.slideshare.net
メールに使われるSMTPには認証のしくみはない
そのために、追加機能で認証をかけることになる
その他、メール系はセキュリティ・スパム対策のためにいろいろ考慮が必要
OAuth
- OAuth : Open Authentication
OAuthとは、「認可情報の移譲」のための仕様のこと。ざっくりいうと以下のとおり。
- あらかじめ信頼関係を構築したサービス間で、
- ユーザーの同意のもとに、
- セキュアにユーザーの権限を受け渡しする。
これを行うことで、ユーザーの認可のもとで別のサービスの管理するCRUD操作などを行えることになります。
2.で同意したら、ユーザーは外部サービスにパスワードを教えること無く、3.の認可情報の移譲ができます。
認可情報は、有効期限や適用範囲を指定でき、必要最低限の権限のみを移譲することができます。
これがOAuthがベーシック認証に比べて柔軟かつセキュアと呼ばれる所以。
また、OAuthは認可を行うための仕様。
ちなみに、認可＋認証（OpenID）をセットにしたのがOpenID Connector
で、OpenID Connector でID Tokenに、JWTが採用されている
JWT
- JSON Web Tokenの略。読み方は"jot"（ジョット）。
- JSONに電子署名を加え、URL-Safeな文字列にしたTokenのこと。
- URL-Safeとは、URLに含めることの出来ない文字を含まないこと。
- 触り心地としての性質
ページのルーティング
SPAの文脈で使われる「ルーティング」とは、表示されているDOMをJavaScriptで書き換え、ページ遷移を擬似的に再現すること
- HTMLベースの静的サイトやサーバーサイドの動的サイトの場合、ルーティングはhttpリクエストに紐づく純粋な「ページ遷移」
- SPAの場合、コンテンツ部分などの対象となるDOMだけを書き換え、「見た目上」のページ遷移を再現可能。
ただし、「URLの変更が行われない」ため、URLをキーとする解析ツールや、検索ボットなどが正常に動作しなくなる。
- 最近のJavaScriptフレームワークでは、「URL変更されない」問題に対してそれぞれ独自のルーティングライブラリを使うことで対応している
- Angularもその例に漏れず、パッケージの一つとして@angular/routerを持っている
状態管理
状態の管理はサーバ、クライアントどっちでやるか。
SPA vs ServerSide
SPA を採用する主なメリット
- 通常のWeb ページでは実現できないUX
- 高速なページ遷移
SPA を採用することによる主なデメリット
- 実装コストが大幅に増える。
- 初期ローディングにかかる時間が増える。
- 開発者が少ない。
どのような場面で採用するべき？
ユーザーが頻繁にページ遷移やコンテンツの操作を行う滞在時間の長いサービス
- 例えば、データ可視化サービスやチケットの座席指定などはユーザーが繰り返し検索を行うため、SPAに向いている。
- このようなサービスを従来のWebページで実装すると、検索が行われる度にページ遷移が発生し、頻繁に待ち時間が発生してしまいます。
一方で、ブログのように直帰率が比較的高いサービスはSPAにはあまり適していない。
- SPAは、サービスに最初にアクセスしたときの読み込みやセットアップにより多くの時間を必要とする。
- 直帰率が高いサービスにSPAを採用しても、アクセス時にかかる時間が増加するだけであまりメリットは無い。
トークンの保管方法、有効期限
CookieとTokenの最も大きな違いはCookieがstateful・TokenがStatelessという点。
- Cookieはサーバ側でsession情報を持つ。
Tokenはクライアント側で「認証に成功した」という情報（＝Token）を持つ
- リクエストの都度それを送る。
- 意味的には、各個処理は独立した処理として扱える
Local storage
- Cookie
- Session storage
- Local storageの注意事項 ＋ ブラウザが閉じられたらTokenが消える。
