認証と認可について調べてみた
はじめに
こんにちは、SHIFT の開発部門に所属しているmurasawaです。今期より中途で入社、バックエンド関連の開発を担当しています。
現在、研修でデータベースやRestAPIについて基本的な事から学んでいます。学んだことをアウトプットし理解を深めていくとともに技術の共有として役に立てば幸いです。
今回は認証と認可の違い、また実際にwebサービスなどで用いられている仕組みであるOpenid connectとOAuth2.0の違いについて最初のさわりとしての情報を調べました。
また、参考として深い理解につながるわかりやすいサイトをご紹介します。
認証と認可
何となくわかっているつもりで分かっていないこの二つの違いを説明していこうと思います。
認証:Authentication
「何者であるか(人、物、PCなど)」を証明することです。
本人限定受取郵便を受け取る際に身分証明書を提示したり、
予約した商品を受け取る際の本人確認など、自分が何者なのかを確認する処理を認証といいます。
最も身近な例ではログインIDとパスワードでどのユーザーかを確認する処理も認証です。
認可(承認):Authorization
たいして、認可は「権限があるか」の確認です。
ログインIDとパスワードが一致して自身のアカウントでログインした後、目的のwebサイトにアクセスしようとしました。
ログインはできているため、認証は完了しています。
しかし、目的のサイトにはアクセスできませんでした。
認証が完了したアカウントでは「権限」がなかったためです。
この権限があるかの確認が認可になります。
身近な例では、お酒を買おうとして、身分証を提示しました。
どこの誰かはわかり、怪しいものでないことはわかりましたが、まだ19歳です。
お酒は20歳からなので販売を許可できません(買う権限がありません)と販売を拒否されます。
認証と認可の関係
ログインIDとパスワードで認証し、「何(どのユーザー)であるか」を確認する、認証で確認した対象物(ユーザー)が何が認可されているか(何の権限があるのかを確認する)という、違うものでありながら深い関係があります。
OAuth2.0
OAuth2.0は上述した認可の仕組みになります。
手頃で楽であるとAOuthで認証の代替のように使っている場合もあるようですが、セキュリティ的には大きな穴があります。
簡単に書くと
OAuth2.0 で認証をするということは、有効なアクセストークンをもって認証できたとみなしていることになります。
しかしアクセストークンは「いつ」「どこで」「なんのために」作られたのか分かりません。
つまり悪意があるサイトなどが、ユーザーから取得したアクセストークンを別サイトのログインに使ってなりすますなどの危険性があります。
一例を下図に示します。
上記の図のアプリケーションが悪意のあるアプリだった場合、access_tokenが有効でさえあれば良いので、ユーザーに簡単に成りすますことができます。
OpenID Connect
OpenID ConnectはOAuthをもとに認証を行えるようにした仕組みです。
OAuth 2.0 + Identity Layer = OpenID Connect と考えてよさそうです。
OAuth2.0との違いはID_tokenが発行されることです。
ID_tokenはアクセストークンとは異なり「いつ」「どこで」「なんのために」発行されたトークンなのかの情報を含んでおり、かつ署名されているため改ざんができません(改ざんを検知できる)。
またフローによってid_tokenのみを発行したり、access_tokenとid_tokenの両方を発行することがありますがaccess_tokenとid_tokenの両方を発行する場合を例に下図に示します。
ID_tokenがあることで認証と認可を行うことができます。
終わりに
今回は簡単に例を交えて説明しましたが、 もっと理解が進み、認証認可についてもっと深く説明できるようになったら、新しく記事を書きたいと思っています。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて(コーポレートサイト)
https://www.shiftinc.jp/
SHIFTのサービスについて(サービスサイト)
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/