どうも、シローです。
今回は認証と認可の違いについてです。
両方とも似た意味として捉えがちですが、そんなことは全然ないので
サーバサイドのエンジニアとしては抑えておきたいポイントかもです。
認証とは「What are you?(あなたは何者ですか?)」
例えば、あなたがホテルを予約して当日チェックインするとします。
そしたら、ホテルの受付の人は「お名前を伺ってもよろしいでしょうか?」と聞きます。
その時、予約をした時と同じ名前で答えて本人確認証を見せれば、受付の人は「ああ、予約した人ですね、OKです」というし、
予約した時の情報と違うと「お前のことは知らんわ」と門前払いをするでしょう。
これが認証です。
要は、ユーザが提示した情報を元にシステムにアクセスしても良いかどうかを検証する第一の門番です。
認証の種類としては
- パスワード認証
- 他要素認証(電話番号)など個人の所有物も正しいかを確かめる
- 生体認証(指紋など)
があります。
もし認証がなかったら、
- ホテルに予約した人とは別の人が名前を名乗るだけで利用できちゃったり
- このブログが全く関係ない人が好きなように編集することができちゃったり
ということになっちゃいますね。
Webサービスとか関係なく、あらゆる事に本人確認としての認証は必要と言えます。
認可とは「What can you do?(あなたは何ができますか?)」
あなたはホテルに無事チェックインできました。
ただ、あなたがそのホテルが提供するサービスの内、受けることができるのは限られているはずです。
例えば、プレミアムクラスで予約すれば豪華なディナーを食べることができたり、個室の露天風呂が利用できて
エコノミークラスで予約すれば値段は安いけど、食事はセルフサービスでお風呂は共有温泉だったり、など。
これが認可です。
要は、認証を通り抜けたユーザがそのシステムに対して何をすることができるかを検証する第二の門番です。
例えば、このブログでも
- 管理ユーザなら記事の追加や編集、他のユーザの管理をすることができて
- 協力ユーザなら記事の追加や編集のみができて
- 一般ユーザなら記事の閲覧しかできない
など、ログインできたユーザにもやれることが決められていて、自分の権限以外のことはできないようになってます。
特にブログやコミュニティサービス、物販サービスのような特定の人に閲覧や編集されたくないことを保証するために認可は必要になります。
必ず認証→認可の流れ
ここまで、認証と認可について整理しました。
認証はユーザがシステムにアクセスできる本人かを確認することで
認可はそのユーザがシステムに対して何ができるかを確かめることです。
そのため、認可は認証を通過したユーザによって行われます。
認可されているということは認証されていることを意味しています。認可されているユーザの集合は認証されているユーザの部分集合といった感じです。
↑、図にしてみました。イメージ伝われば嬉しいです。
認証が第一の門番、認可が第二の門番
まとめ
- 認証はユーザの本人確認を行うこと
- 認可はユーザが何ができるかを制御すること
- 認可は認証されたユーザに対して行う
Webは誕生から20年で爆発的な普及を果たし,17億人のユーザと2億台のサーバを抱える巨大システムへと成長しました。Webがここまで成功した秘密は,その設計思想,いわゆるアーキテクチャにあります。Webのアーキテクチャ,そしてHTTP,URI,HTMLといったWebを支える技術は,Webがどんなに巨大化しても対応できるように設計されていたのです。
私たちが作る個々のWebサービスも,Webのアーキテクチャにのっとることで成功へとつながります。Webのアーキテクチャに正しく適応したWebサービスは,情報が整理され,ユーザの使い勝手が向上し,ほかのサービスと連携しやすくなり,将来的な拡張性が確保されるからです。
本書のテーマは,Webサービスの実践的な設計です。まずHTTPやURI,HTMLなどの仕様を歴史や設計思想を織り交ぜて解説します。そしてWebサービスにおける設計課題,たとえば望ましいURI,HTTPメソッドの使い分け,クライアントとサーバの役割分担,設計プロセスなどについて,現時点のベストプラクティスを紹介します。