晴耕雨読

working in the fields on fine days and reading books on rainy days

認証・認可のフロー

on Protocol

ソーシャルログイン

外部ソーシャルネットワークを使って、Webサービス側のユーザ新規登録処理を簡単にする仕組み。 例：「Login with Twitter」「Login with GitHub」

                                                _____
  .--------. -----(1)----> +-------+           (_____)
  | Client |               |  SNS  | <--(2)--> | DB  |
  '--------' <----(3)----- +-------+           (_____)
      ^  |
      |  |                                       _____
      |  +------(4)--> +------------+           (_____)
      |                | WebService | <--(5)--> | DB  |
      +---------(6)--- +------------+           (_____)
  1. ユーザはID、パスワードを送信する (1)
  2. SNSサーバはID管理DBで認証する (2)
  3. SNSはユーザに同意を求める
  4. ユーザにアクセストークンを送信する (3)
  5. ユーザはWebサービスにアクセスを送信する (4)
  6. WebサービスはID管理DBで認可する (5)
  7. サービス提供を開始する (6)

FIDO

FIDOの仕様には「UAF」と「U2F」の2つの規格があります。

  • UAF : 認証器（指紋認証や顔認証などの生体認証）を使った認証の仕組み
  • U2F : ID、パスワードに加えて二要素認証としてセキュリティコードやセキュリティキーを使った認証の仕組み

認証の流れとしてはチャレンジレスポンス方式です。

        User
         ^
         |(4)                 Client
  .------V--------. <--(3)--- +------------+ ---(1)--> +-----------------+
  | Authenticator |           | WebBrowser | <--(2)--- | FIDO AuthServer |
  '---------------' ---(5)--> +------------+ ---(6)--> +-----------------+
  1. ブラウザはログインを開始する (1)
  2. 認証サーバはチャレンジを送信する (2)
  3. ブラウザはチャレンジと共に認証を要求する (3)
  4. ユーザは指紋や顔認証などでローカル認証する (4)
  5. 認証器は秘密鍵でチャレンジに署名をする (5)
  6. ブラウザは署名されたチャレンジを認証サーバに送信する (6)
  7. 登録済みの公開鍵で署名を検証する

OAuth 2.0

リソースへのアクセス権の一部をアプリに移譲するための仕組み。

.-----. ---(1)--> +------------+ ---(1)--> +---------------+
| App |           | WebBrowser |           | Authorization |
|     | <--(2)--- +------------+ <--(2)--- | Server        |
|     |                                    |               |
|     | ---(3)-AuthorizationCode---------> |               |
'-----' <--(4)-AccessToken---------------- +---------------+
 ^   |
 |   +-----(5)-AccessToken---------------> +-------+
 +---------(6)---------------------------- |  API  |
                                           +-------+
  1. リソース所有者はアプリに権限を付与する
  2. アプリは認可リクエストを送信する (1)
  3. 認可サーバは認可コードを送信する (2)
  4. アプリは認可コードを使ってトークンリクエストする (3)
  5. 認可サーバはアクセストークンを送信する (4)
  6. アプリはアクセストークンを使ってサービスリクエストする (5)
  7. APIはサービスを提供する (6)

OpenID Connect 1.0

OAuthの認可の仕組みに、認証もできるように拡張した仕組み。 OAuth 2.0 のアクセストークンに加えてIDトークンを送受信することで、認証ができるようになります。

.-----. ---(1)--> +------------+ ---(1)--> +---------------+
| App |           | WebBrowser |           | Authorization |
|     | <--(2)--- +------------+ <--(2)--- | Server        |
|     |                                    |               |
|     | ---(3)-AuthorizationCode---------> |               |
'-----' <--(4)-AccessToken+IDToken-------- +---------------+
 ^   |
 |   +-----(5)-AccessToken+IDToken-------> +-------+
 +---------(6)---------------------------- |  API  |
                                           +-------+

Active Directoryの認証

Kerberos認証を使ったディレクトリサービス。 以下は Active Directory の例。

             ----(1)-----> +------------+            _____
  .--------. <---(3)TGT--- | Domain     | <--(2)--> (_____)
  | Client |               | Controller |           | DB  |
  '--------' ----(4)TGT--> |            |           (_____)
      ^  |   <---(6)ST---- +------------+
      |  |
      |  |
      |  +-------(7)ST---> +------------+
      |                    | FileServer |
      +----------(8)------ +------------+
  1. クライアントは TGT (Ticket Granting Ticket) のリクエストを送信する (1)
  2. ドメインコントローラは認証を行う (2)
  3. ドメインコントローラは TGT を送信する (3)
  4. クライアントは TGT をPCに保管する（認証済みでチケットをもらう資格がある）
  5. クライアントは ST (Service Ticket) のリクエストを送信する (4)
  6. ドメインコントローラは TGT を検証する (5)
  7. ドメインコントローラは ST を送信する (6)
  8. クライアントは ST を送信して、ファイルサーバにアクセスする (7)
  9. ファイルサーバは ST を検証し、認可されているか確認する
  10. ファイルサーバはサービスを提供する (8)

SAML

Kerberos認証のチケットの仕組みをクラウドサービス向けに提供する仕組み・システム。

             ----(1)-----> +------------+            _____
  .--------. <---(3)------ |            | <--(2)--> (_____)
  | Client |               |    IdP     |           | DB  |
  '--------' ----(4)-----> |            |           (_____)
      ^  |   <---(5)SA---- +------------+
      |  |
      |  |
      |  +-------(6)SA---> +------------+
      |                    |     SP     |
      +----------(7)------ +------------+
  1. クライアントはIDとパスワードを送信する (1)
  2. IdP (Identity Provider：認証・セキュリティアサーションの発行) で認証する (2)
  3. ユーザ専用のIdPポータル画面を表示する (3)
  4. クライアントは SP (Service Provider) を選択する (4)
  5. IdPはセキュリティアサーション（KerberosのSTに相当するもの）を発行する (5)
  6. クライアントは選択したSPのURLに自動的にリダイレクトされる
  7. 同時に、SPにセキュリティアサーションを送信する (6)
  8. SPはセキュリティアサーションを検証し認可する
  9. SPはサービスを提供する (7)

参考文献

  • Software Design 2020年11月号, 第1特集 今さら聞けない認証・認可 セキュアなIAMを実現するために覚えておきたいこと, 技術評論社, 2020/10/17
  • OAuth徹底入門 セキュアな認可システムを適用するための原則と実践, 翔泳社, 2019/1/30
View Comments...