TL;DR: この概要では、オープンスタンダードとは何か、なぜ重要なのかについて見ていきます。OAuth 2、OpenID Connect、JWT および SAML など ID で使用するオープンスタンダードについても学びます。オープンスタンダードを理解することは大切ですが、技術仕様のため簡単に圧倒させられてしまいます。

「OAuth 2、OpenID Connect、JWT および SAML など ID で使用するトップのオープンスタンダードの概要」

オープンスタンダードとは何か?

ID を 安全ライトウェイト、ライアブル にする背後のインフラストラクチャはなかなか難しく、きちんとするためにチームの大部分の時間を費やしてしまいがちです。そのオーバーヘッドを削減するひとつの方法はその車輪を再発明するよりも、オープンスタンダードを利用することです。

オープンスタンダードは役割がユーザー、ID プロバイダー、サービス プロバイダーを問わず、アプリの役割や、これら役割が互いに通信する方法を定義するコミュニティや業界主導の仕様です。アプリがお互いやプロバイダーに通信する方法も定義します。これはすべて主要な詳細やコードを危機にさらさないよう操作します。

オープンスタンダードは多数の言語やプラットフォーム、テクノロジで実装でき、多様な組織がその利点を簡単に利用できます。

オープンスタンダードの構成は業界中で基礎的な ID のキーを表す均一の方法を作ると同時に、特定のパスを実装する柔軟性もあります。

「オープンスタンダードは多数の言語やプラットフォーム、テクノロジで実装でき、多様な組織がその利点を簡単に利用できます。」

皆さんがご存知のオープンスタンダード

現代の Web 開発はユーザーがすでに精通している良く知られたオープンスタンダードの範囲に依存しています。Web 開発は判読できる形式でデータを構成するために使用する JSON(JavaScript Object Notation)から Web ページを作成するために使用する HTML(ハイパーテキスト マークアップ言語)、後述するように企業 ID に使用する SAML(セキュリティ アサーション マークアップ ランゲージ)があります。

認証と認可の一般的な4つのオープンスタンダード

OAuth 2

OAuth 2 は OAuth プロトコルの最新版で、多数のデバイスやアプリケーションでの認証フローが向上します。 ユーザーは自分の資格情報を公開しないで、サード パーティ Web サイトに別の Web サイト上の情報への制限付きアクセスを付与できます。

OAuth 2 はアクセスを委託するオープンスタンダードで最も広く使用されているひとつで、ユーザーとしておそらくよく実装されているのを目にしているものです。たとえば、Google アカウント(連絡先など)から情報にアクセスする Web サイトにログインすると、OAuth 2 を通して認証を与えます。OAuth 2 の公式ドキュメントはこちらから、 そして OAuth 2 から成る Auth0 の徹底概要)をご覧ください。

OIDC (OpenID Connect)

OpenID Connect は OAuth 2 の上に構築された追加の ID レイヤーで、ユーザーが自分の身元を伝える ID のチェックプロセスを特定します。

OIDC は ID プロバイダーからユーザーの基本的なプロファイル情報を取得できます。

たとえば、ユーザーが Google または Facebook を通してログインできる Web サイトを訪問すると、そのアプリケーションは Google または Facebook に行き、ユーザーの資格情報を取得します。そのアプリケーションはユーザーの基本的なプロファイルを保存する必要はなく、Google または Facebook のユーザー情報のストレージを利用してアクセスを許可し、そのユーザー情報を検証します。

OpenID Connect は API フレンドリ で、モバイル アプリケーションや Web ベース アプリケーション、全 JavaScript クライアントのほかたくさんのタイプのクライアントで使用できます。OIDC は JSON Web Token の使用を義務付けますが、これについては次で説明していきます。OpenID Connect の公式ドキュメントはこちらをご覧ください。

JWT (JSON Web Tokens)

さまざまなアプリケーションでユーザーデータなどの情報を送信するとき、JSON Web Token を使って実行できます。JSON web token は情報を長い、エンコードされた文字列にハッシュし、それは次の3つのパートに分解できます。

  • ハッシュ アルゴリズムとトークン タイプを宣言するヘッダー
  • ユーザーの名前や、トークンの有効期限や情報カテゴリのようなその他関連情報があるペイロードまたはデータ
  • ヘッダー、ペイロード、およびすべてを一緒にハッシュした秘密から成る署名の検証

JWT は長くなるかもしれませんが、このオープンスタンダードは情報を転送する明快な方法を提供します。jwt.io に行くと、そこにツールがあり、エンコードされた JWT に入れ次のようにデコードします。

JWT - エンコード済み:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT - デコード済み:

ヘッダー:

{
  "alg": "HS256",
  "typ": "JWT"
}

ペイロード:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

署名の検証:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
) secret base64 encoded

JWT はデ ジタル署名 がありますから、検証・信頼できます。このデジタル署名は変更がないことを検証し、JWT はパスされます。JWT についての詳細はこちらをご覧ください。

SAML(セキュリティ アサーション マークアップ ランゲージ)

XML ベースのオープンスタンダードの SAML は組織間の ID 通信がセキュリティで保護されているようにします。これは、従業員がアクセスする必要があるユーザー認証・認可情報を他の組織に通信するとき、企業にとって素晴らしいツールです。利点の一部として次があります。

  • 単一認証を通してセキュリティを強化する
  • シングルサインオン(SSO)アクセス ポイントを利用してユーザー エクスペリエンスを向上させる
  • 認証ポイントが一か所の集中型ユーザーアクセス制御

SAML は シングルサインオン (SSO)形式 を利用します。デジタル署名の XML ドキュメントは企業や、提携した複数のサード パーティ エンティティ間にパスされます。SAML についての詳細はこちらをご覧ください。


要約

これまで学んできたように、オープンスタンダードの柔軟性によって ID 産業が同じ考えを持ち、オーバーヘッドを削減し、ID の基礎的キーを表す均一の方法を作りました。誰もが標準的な方法で実施するとき、さまざまな言語やプロジェクト、チームで流れるその フローは認証や認可で計画したように進むことができます。

Auth0 ではオープンスタンダードを使用しますので、標準的で安全な方法で当社製品とユーザーやクライアントがつながることができます。ID は扱いにくいこともありますが、Auth0 ではユーザーは業界が定義したオープンスタンダードでバックアップされていますのでご安心ください。当社では数分で実装できる安全なソリューションを提供するオープンスタンダードを使用します。当社はユーザー、オープンスタンダードなどすべてをカバーしています。

オープンスタンダードについてさらに学びたい方は、上記に記載のオープンスタンダードの Auth0 ドキュメントをご覧ください。

無料 Auth0 アカウントはこちらから登録してください。