はじめに

OAuth 2.0 は、「委任された承認」の業界標準です。
OAuth 2.0は承認に重点を置いており、認証について規定していません。 OpenID Connect（OIDC）は、OAuth2.0の上に認証レイヤーを追加します。

ここでは、OAuth2.0とOIDCの基本について説明します。

Sync GatewayとOIDC

Sync Gatewayはさまざまな形式のクライアント認証をサポートしています。
Sync Gatewayは、Couchbase Liteとのレプリケーション機能だけでなく、パブリックRESTエンドポイントを提供します。
つまり、クライアントは、Couchbase Liteアプリケーションの場合もあれば、パブリックRESTエンドポイントを介してSync GatewayにアクセスするWebフロントエンドまたは、(Couchbase Liteを使っていない)モバイルアプリの場合もあります。

最もよく使われているCouchbaseSync Gatewayクライアント認証メカニズムの1つが、OIDCです。

OAuth 2.0

OAuth 2.0は委任認証の業界標準であり、市場には多数のOAuthプロバイダーがあります。

たとえば、多くのWebアプリやモバイルアプリで見かける「Facebookでログイン」ボタンを思い出すことができます。これは、OAuth2.0を使用して実装されます。

OpenID Connect（OIDC）

OIDCは、OAuth 2.0の上に標準ベースの認証レイヤーを追加します。

OIDCには、2つの一般的なOIDCフローがあります。暗黙フローと認証コードフローです。

暗黙フローと認証コードフローのどちらが良いか？

暗黙のフローは単純であり、一般的にほとんどのユーザーに好まれています。モバイルアプリには安全なストアがあるため、IDとアクセストークンをデバイスのローカルキーストアに安全に保存できます。

認証コードフローの利点は、セキュリティがわずかに向上することです。これは、OIDCプロバイダーに有効なclient_idとclient_secretが提示された場合にのみ、認証コードと引き換えにトークンがSync Gatewayに付与されるためです。これにより、認証されたクライアントのみがトークンを取得できるようになります。また、更新トークンを使用すると、エンドユーザーが毎回資格情報を入力しなくても認証セッションを更新できます。

JSON Web Token（JWT）

Identity Server（OIDCプロバイダー）は、IDトークン（IDトークン）を要求元のアプリに配信します。

IDトークンは、ユーザーの認証に関する「クレーム」をエンコードする標準的な方法です。「クレーム」は、ユーザーに関するアサーションです。

OIDCの重要な要素は、JSON Web Token（JWT）と呼ばれる標準形式でエンコードされたセキュリティトークンであるIDトークンです。JWTはデジタル署名されています。

以下は、典型的なクレームのセットを持つJWTの例です。

{
  "sub": "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4",
  "name": "Priya Rajagopal",
  "email": "priya.rajagopal@example.com",
  "iss": "https://pk-demo.okta.com/OAuth 2.0/default",
  "aud": "WuRuBAgABMP7_w4K9L-40Jhh",
  "iat": 1622246311,
  "exp": 1624838311,
  "amr": [
    "pwd"
  ]
}

sub: JWTが参照するユーザー
iss: JWTに署名するJWTの発行者
aud: トークンの対象者
iat: 発行されたタイムスタンプ
exp: 有効期限のタイムスタンプ
amr: トークンの発行に使用される認証方法

jwt.ioは、JWTのデコードと検証に役立ちます。

参考情報

OAuth 2.0 Playgroundは、OAuth認証フローの理解を助けてくれます。