はじめに
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認証フローの理解を助けてくれます。