業務にてOpen ID Connect(OIDC)を使った認証の仕組みを作ったが, いまだにOIDCがどういったものであるかを理解しないままだった。

そんな中, Software Design 2020年11月号にて認証・認可が取り上げられていたので, その中でOIDCについて詳しく書かれていた第2章ついてまとめる。

第2章 認証・認可のしくみとフロー ~ FIDOからOAuth, SAMLまで一挙に解説 ~

ソーシャルログイン

外部のソーシャルネットワークサービス(Facebook, Twitterなど)を使って認証を行い, その結果をもって対象のWebサービスの認可を行う仕組み。対象のWebサービス側のID管理データベースへの新規登録を大幅に簡素化することができる。

Fast IDentity Online (FIDO)

生体認証を中心とする新しいオンライン認証技術。その名のとおり, 高速なオンライン認証を実現する。WebサービスではなくFIDO認証サーバで認証処理を行う。

Open Authorization (OAuth)

アプリ(Oauthクライアント)がユーザーの代わりにAPI(リソース)にアクセスすることを許す(権限移譲する)認可フレームワーク。これによって, Facebookにログイン(認証)したあとは, Instagramも利用(APIアクセスを認可)できるようになり, パスワードをサービスごとに設定・送信する手間から開放される。

OAuth 2.0

以下の点がOAuth 1.0と異なる。

  • Webサービスだけでなくスマホアプリも対象
  • アクセストークンを受け渡す仕組みを改善
  • HTTPSが必須

以下の4種類の認可フローが用意されている。比較的よく使われるのがAuthorization Code Grant。

以下がOAuth 2.0の仕組みである。スマホアプリは, 認可サーバの「認可エンドポイント」から認可コードを発行してもらう。次に, スマホアプリはアクセストークンを発行してもらうために, HTTPリクエストのペイロード部分に「grant_type=authorization_code&code=<認可コード>」という形で認可コードを入れ, 認可サーバの「トークンエンドポイント」に提出する。こうして取得したアクセストークンをHTTPリクエストのヘッダ部分などに「Authorization: Bearer <アクセストークン>」のように入れ, APIに提出する。

あくまで認可のしくみであり, 認証のしくみについては定義されていない。

リフレッシュトークン

アクセストークンを更新するためのトークン。

Webサービスは認証・認可のあと, HTTP Cookieによってユーザーを特定しているが, APIはトークンによって実行権限の有無を判定する。このトークンに, アクセストークンとリフレッシュトークンが含まれている。

OpenID Connect (OIDC)

認証結果を含むアイデンティティ情報も受け渡しできるようにOAuth 2.0を拡張したプロトコル。認証結果を含むアイデンティティ情報を「IDトークン」に入れて受け渡す。

アイデンティティ情報とはユーザーの属性情報や認証した日時などの情報であり, これをAPI側が確認できるようになる。

Enterprise Identity and Access Management (EIAM)

エンタープライズのためのIAM。コンシューマー向けはこれに大してCIAMと呼ばれる。

前者ではUXが最重要課題とされるが後者ではコーポレートガバナンスが最重要課題とされる。

ローカル認証

システムごとに認証・認可する仕組み。ユーザーやシステムが増えるごとにID管理やパスワード運用が問題になる。

ディレクトリサービス

組織内のメンバーの属性情報や設定情報とネットワーク内のリソース情報をまとめて管理し検索できるようにするサービス。

Lightweight Directory Access Protocol (LDAP)

ディレクトリサービスにアクセスするための通信プロトコル。LDAPサーバとしては, Microsoft社の「Active Directory」とオープンソースの「OpenLDAP」が有名である。

Active Directoryの場合, ID管理を一元化して認証を統合し, 認証と認可を分離できる。「ドメイン」とよばれる管理領域の中に, メンバー情報や権限情報が格納されていて, それを「ドメインコントローラ」というサーバで管理・認証する。

ケルベロス認証

ドメインコントローラにて使われる認証の仕組み。認証をクリアすると, Ticket Granting Ticket (TGT) と呼ばれる認証済みでありチケットをもらう資格を持っていることを証明するためのチケットが発行される。それと引き換えにService Ticket (ST) という各サービスにアクセスするときに必要なチケットが発行される。

Single Sign On (SSO)

異なるドメイン間で設定された信頼関係によって, 自身が所属するドメインで認証し, 異なるドメインのシステムへのアクセス権を取得する機能。

Security Assertion Markup Language (SAML)

セキュリティアサーションというケルベロス認証のチケットのようなものをパスワードの代わりに受け渡すことで, クラウドサービスに対してもSSOを実現する。

Identity Provider (IdP) Initiated

SAMLプロトコルの認証フローの1つ。Webブラウザを使ってIdPのURLにアクセスするところから通信が始まる。

Service Provider (SP) Initiated

SAMLプロトコルの認証フローの1つ。SPのURLにアクセスするところから通信が始まる。

SAMLプロトコルとOIDCプロトコル

共通点

  • 認証と認可を分離
  • 秘密情報を一元管理
  • HTTPS

相違点

  • ユーザー情報の記述フォーマット
    • SAMLはXMLフォーマットのセキュリティアサーション, OIDCはJSONフォーマットのIDトークン
  • 用途
    • SAMLはWebブラウザベースのクラウドサービス, OIDCはそれ以外にも(ex. スマホアプリ)

感想

EIAMとCIAMという異なる目的からプロトコルの標準化が行われた結果, 最終的に似たような認証・認可のしくみができるという流れがとても面白いと思った。今度はSSL/TLSに関する本を読もうと思っている。