あれ、認証・認可についてちゃんと説明できるっけ。。
はじめに
- なぜこんな記事を書こうと思ったかというと、認証・認可について僕がなあなあになっている気がしたので、改めて自分の中で整理したかった為です。
認証 (Authentication)
あるウェブサイトにユーザがログインした際に誰なのかを確認することを指します。
本人確認をイメージすると分かりやすいかもです。
認可 (Authorization)
認証したユーザに対して、リソースのアクセス権限をどこまで与えるか決定することです。
フェデレーテッドログイン
これは、例えばあるサービスがあった場合にそのサービス以外が管理するIDを利用してログインする方法です。
実装パターン
以下に実装パターンをいくつか紹介しますが、だいたい今はOAuth 2.0かOpenID Connect(別記事で書きます。)ですねw
シングルサインオン
シングルサインオンは、各システム間のアカウント管理を別々に行わず、一度認証したら全システムが全て有効になるような仕組みです。
また、シングルサインオンにはいくつか方法があります。
一つ例にあげるのであれば、あるサービスがあった時、そのサービスが認証サーバにユーザIDとパスワードを利用しアクセスしにいく方法があります。
kerberos認証
kerberos認証は、はじめにユーザIDとパスワードを使って認証し、以降は身元証明書（チケット）を使って認証する方法です。
もう少し詳しく説明すると、ユーザがサービスを使用するときは、まずチケット保証サーバ(TGS)へのアクセストークンであるTGT(Ticket Granting Ticket)とセッションキーを取得します。
その後、TGTとセッションキーをチケット保証サーバに送り、クライアントからサーバにアクセスするためのチケットとセッションキーをもらいます。
そして、ユーザはこのチケットとセッションキーをサービスに送るということで認証をする仕組みとなります。
SAML
-
SAML(Security Assertion Markup Language)は、HTTP/SOAPを前提としたシングルサインオンの仕組みです。
-
この仕組み、奥深いので実装方法については、HTTP POST /Redirect バインディングに絞り説明します。
-
特徴としては、クッキーを使ってセッションを管理するウェブの仕組みに準拠しており、ドメインをまたぐサービス間でシングルサインオンができます。
構成要素
ユーザ
ブラウザを操作している人
認証プロバイダー (IdP)
ID管理をするサービス
サービスプロバイダー (SP)
ログインしたいサービス
HTTP POST /Redirect バインディングによる実装
下記のような流れで認証/認可を行います。
-
1.ユーザはログインされていない状態で、ユーザがSPにアクセスします。
-
2.SPはブラウザにRedirectのhttp status(3XX)を返します。
-
3.IdPはユーザが認証の要件を満たすログインコンテキストをIdpに持ってるかを判断します。
もしなければ、ユーザに正しいID/Passwordを提供するようにブラウザから要求します。 -
4.ユーザはID/Passwordを入力し、IdPでそのユーザに対するセキュリティコンテキストが作成されます。
-
5.IdPはユーザのセキュリティコンテキストを表すSAMLアサーションを作成します。
-
6.ブラウザは5で取得したSAMLアサーションをSPに送信するHTTPリクエストを発行します。
-
7.ユーザがリソースにアクセスする権限があるかチェックをし、通ればリソースをブラウザに返します。
OAuth2.0
構成要素
認可サーバ
ユーザ情報を持つウェブサービス。
ユーザは、この認可サーバのアカウントを持っています。
リソースサーバ
ユーザが許可した権限で自由にアクセスできる対象。
クライアント
ユーザが新たに利用したいサービスやアプリケーション
認証フロー
いくつかフローがあるのですが、今回は抜粋して通常のフローのみに絞り説明します。
Authorization Code
通常のフローです。
今回はPKCEは置いておきます。
流れとしては、認可サーバに認可リクエストを送信し、認可コードを受けとります。
その認可コードを再度、認可サーバに送信してアクセストークンと交換するようなフローになります。
-
アクセストークン発行までのやり取り
-
リソース返却までのやり取り
参考文献
Discussion