JetBrains Space ヘルプ

リソース所有者のパスワード認証情報フロー

基本

  • Space ユーザーに代わって承認を行います。

  • アプリケーションが知っている資格情報をユーザー (リソース所有者) に代わってリソースにアクセスするアプリケーションに適しています。アプリケーションは、たとえば、デバイスのオペレーティングシステムや高度な特権を持つアプリケーションなどです。

  • 通常、アプリケーションは対話型フォームを介してユーザーの Space 認証情報 (ユーザー名とパスワード) を取得します。次に、アプリケーションはこれらの認証情報を使用して、ユーザーに代わって Space へのフルアクセスを取得します。

  • フローの詳細については、リソース所有者のパスワード認証情報フローの仕様(英語)を参照してください。

実装方法

リクエスト

Space からアクセストークンを取得するには、アプリケーションはトークンエンドポイント <Space service URL>/oauth/token にリクエストを行う必要があります。

リクエストの HTTP ヘッダーに次のパラメーターを追加します :

client_id

必須。クライアントアプリケーションを Space に登録するときに割り当てられる ID。クライアント ID を取得するには、administration.png 管理→ アプリケーションに移動し、リストからアプリケーションを選択します。

client_secret

必須。クライアントアプリケーションを Space に登録するときに割り当てられるプライベート ID。クライアントシークレットを取得するには、administration.png 管理→ アプリケーションに移動し、リストからアプリケーションを選択します。

UTF-8 文字エンコーディングの application/x-www-form-urlencoded 形式の HTTP リクエストのエンティティボディに次のパラメーターを追加します :

grant_type

必須。OAuth 2.0 リクエストの許可タイプを指定します。値を password に設定します。

ユーザー名

必須。リソース所有者のユーザー名。

パスワード

必須。リソース所有者のパスワード。

範囲

必須。Space 内の特定のリソースにアクセスするために必要な権限の Space 区切りのリスト。

権限スコープの形式の詳細については、こちらを参照します。

access_type

ユーザーがオンラインでないときにアプリケーションが Space にアクセスする必要があるかどうかを示します。許可される値: online (デフォルトで使用) および offline ユーザーがオンラインでないときにアプリケーションでアクセストークンのリフレッシュが必要な場合は、offline 値を使用します。この場合、Space は初めてユーザーの認証コードを交換するときに、アプリケーションのリフレッシュトークンを発行します。詳細については、「リフレッシュトークン」ページを参照してください。

リクエストには、次の形式の「Authorization」ヘッダーが含まれている必要があります。

Authorization: Basic <base64(client_id + “:” + client_secret)>

正しい値を取得するには、区切り文字としてセミコロンを使用し、Base64 形式にエンコードする(英語)を使用して client_id と client_secret を 1 つの文字列に結合します。

例: アプリケーションはトランスポート層セキュリティを使用して次の HTTP リクエストを作成します。

POST /oauth/token Host: jetbrains.team Authorization: Basic dmFsaWQtc2VydmljZS1pZDp2YWxpZC1zZXJ2aWNlLXNlY3JldA== Content-Type: application/x-www-form-urlencoded grant_type=password&scope=**&username=user_example&password=password_example&access_type=offline

リクエストが有効な場合、Space はアプリケーションを認証します。

レスポンス

アクセストークンリクエストが有効で承認されている場合、Space サーバーはアクセストークンとリフレッシュトークンを発行します。

例:

HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "token_type": "Bearer", "expires_in": 600, "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIzNThlMDRlOS1jNDc1LTRkNGUtOGM4OS1lODA3ZTQxNjk3MmMiLCJhdWQiOiIzNThlMDRlOS1jNDc1LTRkNGUtOGM4OS1lODA3ZTQxNjk3MmMiLCJvcmdEb21haW4iOiJqZXRicmFpbnMudGVhbSIsInNjb3BlIjoiKioiLCJuYW1lIjoiTXkgU2VydmljZSIsImlzcyI6Imh0dHBzOi8vamV0YnJhaW5zLnRlYW0iLCJwcmluY2lwYWxfdHlwZSI6IlNFUlZJQ0UiLCJleHAiOjE1NjQ1MDU0MzAsImlhdCI6MTU2NDUwNDgzMH0._1uLmGWUfeG52p4_LcLdZN29at14CGG_RE4KusWY34A", "refresh_token": null, "scope": "**" }

エラー

リクエストがアプリケーション認証に失敗した場合、または無効な場合、Space は HTTP 400 (間違った要求) ステータスコードで応答し (特に指定されていない限り)、応答には次のパラメーターが含まれます。

エラー

以下からの単一の ASCII [USASCII] エラーコード:

  • invalid_request — リクエストに必須のパラメーターが欠落している、サポートされていないパラメーター値（許可型以外）が含まれている、パラメーターが繰り返されている、複数の資格情報が含まれている、アプリケーションを認証するために複数のメカニズムを利用している、またはその他の形式が不正です。

  • invalid_client — アプリケーション認証に失敗しました (例: 不明なアプリケーション、アプリケーション認証が含まれていない、サポートされていない認証方法)。認証サーバーは、サポートされている HTTP 認証スキームを示すために、HTTP 401 (Unauthorized) ステータスコードを返す場合があります。アプリケーションが「Authorization」要求ヘッダーフィールドを介して認証を試行した場合、Space サーバーは HTTP 401 (Unauthorized) ステータスコードで応答し、アプリケーションが使用する認証スキームに一致する「WWW-Authenticate」応答ヘッダーフィールドを含めます。

  • invalid_grant — 提供された認可付与 (認可コード、リソース所有者の資格情報など) またはリフレッシュトークンが無効であるか、期限切れであるか、取り消されているか、認可リクエストで使用されたリダイレクト URI と一致しないか、別のアプリケーションに発行されました。

  • unauthorized_client — 認証されたアプリケーションには、この認可付与タイプを使用する権限がありません。

  • unsupported_grant_type — 認可付与タイプは、Space ではサポートされていません。

  • invalid_scope — 要求されたスコープが無効、不明、不正な形式であるか、リソース所有者によって付与されたスコープを超えています。

error_description

追加情報を提供する人間が判読可能な ASCII [USASCII] テキスト。アプリケーション開発者が発生したエラーを理解できます。

パラメーターは、「application/json」メディア型を使用して HTTP レスポンスのエンティティ本体に含まれます。パラメーターは、最上位の構造レベルで各パラメーターを追加することにより、JSON 構造にシリアル化されます。パラメーター名と文字列値は JSON 文字列として含まれています。数値は JSON 番号として含まれています。パラメーターの順序は重要ではなく、変化する可能性があります。

例:

HTTP/1.1 400 Bad Request Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "error":"invalid_request" }
暗黙的なフロー OAuth 2.0 エラー