Oracle Cloud Infrastructureドキュメント

暗黙的権限付与タイプ

この権限付与タイプは、カスタム・アプリケーションでクライアント資格証明の機密を保持できず、中間の権限コードではなく認可リクエストから直接アクセス・トークンを受信する場合に使用します。

次のダイアグラムに、暗黙的な権限付与タイプのフローを示します。

暗黙的な権限付与タイプのフローを示す図。

このOAuthフローでは、次のようになります。

  1. カスタム・アプリケーションは、たとえば、JavaScriptなどのスクリプト言語を使用してクライアント側アプリケーションに実装された、またはモバイル・デバイスに実装されています。ユーザーは、アプリケーションを介して認可と認証をリクエストします。

  2. クライアント・アプリケーションは、ユーザーに資格証明を入力するように要求します。

  3. ユーザーは自分の資格証明を入力します。

  4. 認可されると、ユーザーは、URLフラグメントにアクセス・トークンを含むURLにリダイレクトされます。

  5. アプリケーションは、URLからアクセス・トークンを抽出します。

  6. クライアント・アプリケーションは、保護されているリソース(ユーザーのリストなど)に対するリクエストでアクセス・トークンを使用します。

機能 使用可能
クライアント認証が必要 いいえ
クライアントがユーザー資格証明を認識する必要があります。 いいえ
ブラウザベースのエンド・ユーザーとの対話 はい
認証のために外部アイデンティティ・プロバイダの使用が可能 はい
リフレッシュ・トークンを許可 いいえ
アクセス・トークンがエンド・ユーザーのコンテキスト内 はい

暗黙的な権限付与タイプの認可のフローの例を参照してください。

暗黙的な付与タイプの認可フローの例

この暗黙的な権限付与タイプの認可例では、JavaScriptなどのスクリプト言語を使用してWebブラウザに実装されたアプリケーション、またはモバイル・デバイスに実装されたアプリケーションの認可フローについて説明します。アクセス・トークンは、中間認可コードではなく、リソース所有者の認可リクエストに応答してブラウザ・リダイレクトを介してクライアントに返されます。

アイデンティティ・ドメイン・コンソールでクライアント側アプリケーション認可用のアプリケーションを作成する場合:

  • これが「モバイル・アプリケーション」タイプであることを指定します。

  • 権限付与タイプとして「Implicit」を選択します。このタイプのアプリケーションは、シークレットを保持できず、未承認のWebブラウザまたはモバイル・デバイス上で実行されます。

暗黙的な権限付与タイプおよび認可フロー・ダイアグラムの詳細は、暗黙的な権限付与タイプを参照してください。

処理ステップ

  1. ユーザーは、ブラウザ・アプリケーションのサインイン・リンクをクリックするか、デバイス上のサインイン・ボタンをタップして、クライアント・アプリケーションから保護されたリソースへのアクセスをリクエストします。

  2. クライアントは、認証のリクエストを使用して、OAuth認可サーバーにブラウザをリダイレクトします。

    サインインURLには、リクエストされているアクセスのタイプを示す問合せパラメータが含まれます:

    リクエストの例 https://acme.identity.us.oraclecloud.com/oauth2/v1/authorize?client_id=<client-id>&response_type=token&redirect_uri=<client-redirect-uri>&scope=<scope>&nonce=<nonce-value>
    ノート

    nonce値は、インターセプトされたレスポンスが再利用されるのを防ぐのに使用する、暗号化された強力なランダム文字列します。

    mTLSを使用したリクエストの例

    secureDomainURLの取得方法については、「アクセス権限タイプ」を参照してください。

    curl -v \
--cert cert.crt \
--key key.key \
--cacert ca.crt \
--location '<secureDomainURL>/oauth2/v1/token' \
--header 'Authorization: Basic <base64Encoded clientid:secret>'
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=<client-id>' \
--data-urlencode 'scope=urn:opc:idm:_myscopes_'

  3. ユーザーがまだログインしていない場合は、OAuth認可サーバーはユーザーの認証を試みます。OAuth認可サーバーは、ユーザーを認証し、ユーザーが情報の共有を認可するための承諾ページを表示します。

  4. ユーザーの認証後、OAuth認可サーバーはアクセス・トークンとともにリクエスト・サイトにブラウザをリダイレクトします。
    ノート

    ユーザーが認証しない場合は、アクセス・トークンではなくエラーが返されます。

  5. リクエスト側のクライアント・アプリケーションとクライアントのリクエストで指定されるユーザー(ある場合)に付与されたアプリケーション・ロールによって示される権限に基づいて、適用可能なすべてのスコープが含まれるアクセス・トークンが返されます。

  6. リクエスト・サイトは、APIコールでアクセス・トークンを使用して、保護されているデータを取得します。