前 2 回の記事では、 OIDC 認証コードとそれによって拡張された PKCE モードについて紹介しましたが、今回は、OIDC 認証モードの 1 つである (Client Credentials) モードに焦点を当てます。クライアント (アプリケーション) が独自の名前で OIDC サーバーからアクセス トークン (アクセス トークン) を取得する認証モードで、API または IoT シナリオを保護するためによく使用されます。
[ Authingは、中国で唯一の開発者中心のフルシナリオ ID クラウド製品であり、1000 以上の API とすべての主流言語 SDK を提供し、数十万の開発者によるコミュニティ エコロジーを持っています。】
01. クライアントの認証情報
クライアント認証情報モードは、ユーザーの参加なしでサーバー間の認証 (M2M 認証) に使用されます。事前にプログラミング アクセス アカウントを作成し、AK キーと SK キーのペアをリソースの呼び出し元に引き渡す必要があります。ベンダーによってこれの実装方法が異なることに注意してください。たとえば、Okta と Auth0 によるクライアント資格情報の実装は次のとおりです。 use Client ID と Client Secret は呼び出し側に引き渡され、Authing はアプリケーションでプログラミング アクセス アカウントを作成し、AK/SK を呼び出し側に引き渡します。呼び出し側の使用方法に違いはありません。このメソッドは、呼び出し元が管理する複数のメソッドに適しています。
⚠️ クライアント資格情報モードはリフレッシュ トークンをサポートしません。
全体的には次のようなプロセスがあります。
1.リソースの呼び出し元は、認証情報 AK、SK、および要求される権限のスコープを認証承認エンドポイントに送信します。
2.資格情報が正しく、呼び出し元にリソース権限がある場合、Authing はその呼び出し元に対して AccessToken を発行します。
3.呼び出し元は、access_token を保持してリソース サーバーを要求します。
4.リソース サーバーは、トークンが合格したことを確認した後、関連するリソースを返します。
フローチャートは次のとおりです。
1.1 接続の準備をする
1.1.1 アプリケーションを作成し、Authing で設定する
いつものように、最初に Authing でアプリケーションを作成する必要があります。
認証モードの構成
プログラムによるアクセス アカウントを作成し、API 呼び出し元に付与します。
1.1.2 Auhing で権限を定義し、AK SK アカウントを承認する
注: ユーザー認証中、スコープはユーザー情報に対応し、AK/SK が Token を取得する場合、スコープは認可された API 権限に対応する必要があります。
1.1.2.1 スコープ権限の仕様
Authingのスコープ権限項目はスペースで区切られており、各項目の形式は次のようになります。
リソース:リソース識別子:リソース操作
リソース: リソース識別子: リソース操作。
以下は、Authing でサポートされるすべてのスコープ形式です。
1. 意味は、書籍リソース番号 1 の読み取り許可です。
book:1:read
2. 意味はすべての書籍リソースの読み取り許可です
book:*:read
3. 意味はすべての書籍リソースの読み取り許可です
book:read
4. すべての書籍リソースのすべての操作権限を意味します
book:*:*
5. すべての書籍リソースのすべての操作権限を意味します
book:*
6. すべての書籍リソースのすべての操作権限を意味します
book:
7. すべてのリソースのすべての操作権限を意味します
*:*:*
8. すべてのリソースのすべての操作権限を意味します
*:*
9. すべてのリソースのすべての操作権限を意味します
*
1.1.2.2 認証権限管理で関連リソースを定義する
book リソースを定義します。
1.1.2.3 プログラムによるアクセス アカウントの承認
ここでは、作成したばかりのプログラミング アクセス アカウントの呼び出し元 A を承認し、呼び出し元 A が GET リクエストで /book API にアクセスできるようにし、ID 20150 の注文のみを取得できるようにします。
1.2 アクセステスト
1.2.1 必要な呼び出しインターフェイスのリスト
POST${host}/oidc/token 获取 Token
POST${host}/oidc/token/introspection 校验 Token
POST${host}/oidc/revocation 吊销 Token
1.2.2 Postman での実行
以下に紹介するインターフェイスは、オンラインの郵便配達員コレクションを通じて fork によって体験できます。
1.2.3 トークンの取得
POST${host}/oidc/token
ユーザーが Authing 側でログイン操作を完了すると、Authing は生成されたコードをパラメータとして redirect_uri アドレスにコールバックします。このとき、対応するアクセス トークン access_token は code-for-token インターフェイスを通じて取得できます。
リクエストの例:
curl --location 'https://{host}/oidc/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={AccessKey}' \
--data-urlencode 'client_secret={SecretKey}' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=book:20150:GET book:20150:POST'
応答例 (成功) :
{
"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Il9xcEhRQXFvbXd0Z3BKX2xZVHNtN2FMVEU3YUtJb0tQeFN5by1faDdGUVkifQ.eyJhenAiOiI2M2Y0ODA5OTlkNGY0MDRiZTViNDQ0NGEiLCJhdWQiOiI2M2Y0ODI1ZDhhNWRmNjYyNTU4YjI4MTQiLCJzY29wZSI6ImJvb2s6MjAxNTA6R0VUIiwiaWF0IjoxNjgxNzExNDU2LCJleHAiOjE2ODE3MTIwNTYsImp0aSI6IlBiSks5djNFTS1rS1o3bms4VmdBRms3eVVPRzJES2NwYUQ2M2gxaThmVlkiLCJpc3MiOiJodHRwczovL29pZGMtY2xpZW50LWNyZWRlbnRpYWxzLmF1dGhpbmcuY24vb2lkYyJ9.qPcJU84C9Ztjm5dk-im8ntatPaB5P8j3ZPdW1eoi-V5po8k32jexUemSEHInEfqdxcnY7OyR1pph6JVjehmoCAX6gqA_3fv20hUjnWQNqcZegAiNea4jQbLKlMsYnTQhhJWmzhs64LwCJD1RqQy0VtoL2ZVVfAEpySHWL6TwWVz0AkvQpZbzkF6FRCa03rli_jc1BNtpGUhvNdtGs6xJMMLJZ31dptrLlSSWSQ71t05fqBfEiToN6-JkwKXJedpHBvFWt_-XncQbksdQQc6krTcgaWkrIbv6LblTrtAifXLfOsANweOAG8QoKLh55vSMMBXdzdw-IzXeCDuwQT5P2w",
"token_type":"Bearer",
"expires_in":600,
"scope":"book:20150:GET",
"rejected_scope":"book:20150:POST"
}
ここで、scope はアクセス アカウントによるアクセスを許可するリソース、rejected_scope は申請したが拒否された権限です。呼び出し元 A に book:20150:GET の権限を割り当てただけなので、book をリクエストします。 20150: GET および book:20150:POST 権限を同時に持つ場合、book:20150:POST 権限は拒否され、呼び出し元は access_token を取得した後、そのトークンを使用して保護された API を呼び出すことができます。
応答例 (失敗) :
{
"error": "server_error",
"error_description": "编程访问账号不存在！"
}
1.2.4 トークンの検証
POST${host}/oidc/token/introspection
API サーバーはインターフェイス呼び出しリクエストを受信した後、このインターフェイスを呼び出して、access_token の有効性と、対応する API を呼び出す権限があるかどうかを確認できます。
このエンドポイントは、access_token、id_token、refresh_token を受け入れ、アクティブかどうかを示すブール値を返します。トークンがアクティブな場合、トークンに関する追加データも返されます。トークンが無効、期限切れ、または取り消されている場合、トークンは非アクティブであるとみなされます。
access_token は、RS256 署名アルゴリズムまたは HS256 署名アルゴリズムを使用して署名できます。2 つの署名アルゴリズムの違いは次のとおりです。
RS256 は 、RSA アルゴリズムを使用したデジタル署名アルゴリズムであり、公開キーと秘密キーのペアを使用して情報を暗号化し、検証します。RS256 署名で生成されたトークンは、RSA キー ペアで署名するとより高いレベルの保護が提供されるため、HS256 署名で生成されたトークンよりも安全です。RS256 署名アルゴリズムを使用するトークンは、JWK エンドポイントを通じて取得できる公開キーを使用して検証できます。
HS256 は、対称鍵を使用するデジタル署名アルゴリズムです。署名と検証に同じキーを使用します。HS256 署名アルゴリズムは、署名と検証に RSA 公開鍵/秘密鍵ペアの代わりに対称鍵を使用するため、RS256 署名アルゴリズムよりもパフォーマンスが高速です。HS256 署名アルゴリズムを使用するトークンは、共有シークレット (アプリケーション キー) によって検証できます。
実際のアプリケーションでは、RS256 アルゴリズムの方が安全ですが、より多くのリソースを消費します。システムが高いパフォーマンスを必要とする場合は、HS256 署名アルゴリズムを選択できます。オンライン認証:
リクエストパラメータ:
リクエストの例:
curl --location --request POST 'https://{host}/oidc/token/introspection' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={应用ID}' \
--data-urlencode 'client_secret={应用密钥}' \
--data-urlencode 'token={ token }' \
--data-urlencode 'token_type_hint=access_token'
検証の access_token 応答例 (検証が成功した場合)
{
"active": true,
"aud": "63f4825d8a5df662558b2814",
"client_id": "63f480999d4f404be5b4444a",
"exp": 1681713127,
"iat": 1681712527,
"iss": "https://oidc-client-credentials.authing.cn/oidc",
"jti": "EpveFqLsgskNIre8fK-h0AOK6oBIfZH6erT5iSrRKmd",
"scope": "book:20150:GET",
"token_type": "Bearer"
}
検証の access_token 応答の例 (検証失敗):
{
"active": false
}
1.2.5 トークンの引き出し
POST${host}/oidc/token/revocation
API サービスは、このインターフェイスを通じて呼び出し元の access_token を取り消すことができます。
リクエストパラメータ:
リクエストの例:
curl --location --request POST 'https://{host}/oidc/token/revocation' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id={应用ID}' \
--data-urlencode 'client_secret={应用密钥}' \
--data-urlencode 'token= {token}' \
--data-urlencode 'token_type_hint=access_token'
応答例 (成功) :
HTTP 200 OK
応答例 (失敗) :
{
"error": "xxxx","error_description": "xxxx"
}
02. この章の概要
この章では、API を保護するためのクライアント認証情報モードの使用について紹介し、これまで、OIDC の一般的に使用される認証モードを紹介しました。
[Authing は、中国で唯一の開発者中心のフルシナリオ ID クラウド製品であり、1000 を超える API とすべての主流言語 SDK を提供し、数十万の開発者のコミュニティ エコロジーを備えています。】
以下は、OIDC および OAuth2.0 認証プロトコルのベスト プラクティス シリーズの記事のカタログです。原文を表示するには、リンクをクリックしてください。
OIDC & OAuth2.0プロトコルとその認可モードを詳しく解説｜認証プロトコルベストプラクティスシリーズ[1]
OIDC & OAuth2.0 認可コードモード アクセス認証｜認証プロトコルベストプラクティスシリーズ【2】
2023-04-27 11:45に編集