OpenID Connect または OIDC は、OAuth 2.0の認証・認可メカニズムを採用したアイデンティティプロトコルです。OIDC の最終仕様は、2014年2月26日に発表されましたが、現在では、インターネット上の多数のID プロバイダーによって広く採用されています。

OIDC は、Google や Microsoft などを含む OpenID Foundationにより開発されました。OAuth 2.0 は認可プロトコルである一方で、OIDC は、アイデンティティ認証プロトコルであり、顧客サービスに対するユーザーのアイデンティティを検証するために利用される場合があります。これは、リライングパーティ（認証依存側）とも呼ばれます。さらに、たとえば氏名やメールアドレスなどのユーザーの要求は、必要に応じて共有される場合があります。

多様なクライアントが、シングルページアプリケーション SPA）からネイティブなモバイルアプリまで OpenID Connect （OIDC）を使用することができます。アプリケーション全体にわたるシングルサインオン（SSO）に使うこともできます。OIDC は、JSON Web Tokens ジェイソンウェブトークン）（JWT）、HTTP フローを利用し、サービスとユーザーの認証情報を共有しないようにします。

OpenID Connect には、同意書が組み込まれています。このビルトインの同意書は重要です。OIDC は、消費者向けのサービス（リライングパーティーなど）に利用されることが多く、個人情報の共有にはユーザー側の明示的な同意が必要となるからです。

OpenID Connect は、実装しやすいだけでなく、こうした機能を備えていることから、ユーザー ID が求められる際の便利なプロトコルであり、より複雑な SAML 2.0に代わる強力な代替手段です。特にモバイルアプリにも適しています。

OIDC は、OAuth 2.0 を下位層のプロトコルとして採用しています。主な拡張子は、特別なスコープ値（「openid」）であり、余分なトークン（JSON 形式のＩD 要求をカプセル化するID トークン）を使用し、承認よりも認証を重視しています。また、OIDC における「フロー」という言葉は、OAuth2 の 「グラント」の代わりに使われています。

OIDC プロバイダー（通称、OpenID プロバイダーまたは ID プロバイダー、またはIdP）は、ユーザー認証、ユーザーの同意、トークン発行を実行します。 ユーザーIDを要求するクライアントやサービスは、通常、リライングパーティー（RP）と呼ばれています。たとえば、ウェブアプリケーションだけでなく JavaScript アプリケーションやモバイルアプリでも可能です。

OAuth 2.0 上に構築されているOpenID Connect は、トークンを使って、下位層のフレームワークに統合されたシンプルなアイデンティティ層を提供します。この統合は、次のタイプのトークンを使用していることを意味します：

ID トークン：特にOIDCにおいて、JWT 形式のトークンは主に、認証操作の結果に関する情報を提供するために使われています。要求に応じて、ユーザーのプロフィールを記述するアイデンティティデータを提供することができます。認証結果およびユーザーのプロフィールについてのデータは、クレームと呼ばれます。ユーザープロフィールのクレームは、関連 ID、メールアドレス、氏名など、識別を目的としたリライングパーティーに関するあらゆるデータです。

アクセストークン：OAuth2 で定義されているとおり、この オプションの）有効期間の短いトークンは、認証サーバーへのリクエスト時にスコープ値の定義に従い、特定のユーザーリソースへのアクセスを提供します。

リフレッシュトークン：OAuth2 仕様のこのトークンは、通常、有効期間が長く、新しいアクセストークンを入手するために使う場合もあります。

ID トークンは、改ざんを避けるためのデジタル署名が必要です。多くの場合、トランスポート・レイヤー・セキュリティ（HTTPS）が十分であっても、機密性を強化するため暗号化されることがあります。 SPAsおよびモバイルアプリでは、ID トークンの暗号化は、有用ではありません。暗号解読は、簡単にできるからです。

OpenID Connect フローの選択は、アプリケーションの種類やそのセキュリティ要件によります。一般的なフローには3つあります：

• 暗黙的なフロー:SPA によって一般的に使われているこのフローでは、トークンは、リダイレクト URI で RP に直接返されます。
• 認可コードフロー：トークンは直接返されることはないため、このフローは、暗黙的なものよりも安全性が高いと言えます。ネイティブ/モバイルアプリと SPA のセキュリティは、 コード交換のプルーフキーを使って強化することができます。ハイブリッドフロー：暗黙、かつ認証コードフローを組み合わせることで、ID トークンは、RP に直接返されますが、アクセストークンは返されません。その代わり、アクセストークンに交換される認証コードを返します。

ユーザーが IdP アカウントにサインインし、RP にアイデンティティデータを開示する同意をすれば、OpenID プロバイダーが、ユーザーの認証に使える認証方法を決定します。OIDC 仕様は、ユーザー認証自体の構造に関与することはありません。IdP は、シングルまたは複数の要素を提供します。例：

• ユーザー名/パスワード
• SMS または メールによって帯域外から提供されるシングルユーズコード、
• アプリ（OATH、TOTPまたはHOTP）が作成するコード
• アプリ経由の生体認証
• フェデレーション認証（Facebook、GoogleIDなど）

RP は、IdP 認証に関与することもできます。たとえば、多要素認証がリクエストされる可能性があります。ただし、IdP がユーザーを認証する方法は、OIDCの範疇ではありません。

[IAM 入門ページ]（https://auth0.com/intro-to-iam/）で、さらに多くの、ID とアクセスの管理に関するトピックをご覧ください。