OAuth 2.0 との連携
アプリケーションを OAuth 2.0 認証と連携して、メール サーバーなどのサードパーティ アプリに接続できます。アトラシアンでは 3-legged 認証のみをサポートしています。
基本認証を無効化する
Google や Microsoft などの一部のプロバイダーは、基本認証の無効化を予定しています。無効化されると、メールから課題やコメントを作成することができなくなり、Gmail や Microsoft Exchange Online サーバーへの接続操作ができなくなります。カスタム メール サーバーまたはその他のサービス プロバイダーで IMAP または POP3 が使用されている場合、それらの設定を更新する必要はありません。これらは引き続き動作します。
現在、Jira は、POP3 を介した Microsoft Exchange Online 向けの OAuth 2.0 をサポートしていません。サポートが提供されるまでベーシック認証を引き続き使用するか、IMAP を使用してメール サーバーに接続するか、OAuth 2.0 と統合できます。
メール サーバーのための、OAuth 2.0 プロセスとの連携
Google および Microsoft メール サーバー用に OAuth 2.0 を構成し、メール サーバーの構成を更新する必要があります。これを行うには、システム管理者である必要があります。
最初に OAuth 2.0 設定を行う必要があります。これを行うには、サービス プロバイダーからクライアント ID などの特定の情報が必要となります。このデータは、サービス プロバイダー側で生成できます。次に、そのデータをアプリケーションの OAuth プラグインにコピーしてリダイレクト URL を生成する必要があります。アプリケーションがサービス プロバイダーのサイトで生成したリダイレクト URL を提供する必要があります。設定を保存したら、認証方法として OAuth 2.0 を使用するようメール サーバーを設定する必要があります。
Prerequisites
以下を確認する必要があります。
サーバーには HTTPS 経由でアクセスできる必要があります。これを行わない場合、OAuth 2.0 を構成できなくなります。
ベース URL は正しく設定する必要があります。提供が必要となるリダイレクト URL は Jira のベース URL に基づくため、これは重要です。
Google、Microsoft、または独自のカスタム サーバー用に OAuth 2.0 を構成する
最初に、メール サーバーが使用する OAuth 2.0 連携を追加する必要があります。次に、この連携を使用するメール サーバーを構成する必要があります。
- [Jira 管理] > [システム] > [OAuth 2.0] の順に移動します。
- [新しい統合を追加] をクリックします。
- ご利用のサービス プロバイダーを選択します。
- 連携の名前を入力します。
- Google および Microsoft の場合は、認証およびトークンのエンドポイント データが自動入力されます。ただし、カスタム サービス プロバイダーを使用している場合、サービス プロバイダーからこのデータを取得し、自身で入力する必要があります。
生成されたリダイレクト URL をコピーします。クライアント ID とクライアント シークレットを取得するために、この URL をサービス プロバイダーのサイトで提供する必要があります。
カスタム サービス プロバイダーを構成する場合、[生成] をクリックしてリダイレクト URL を受け取ります。
リダイレクト URL はエンドポイントに依存します。トークン エンドポイントの認証を変更する場合、リダイレクト URL も変更する必要があります。[生成] をクリックして新しい URL を取得します。
7. サービス プロバイダーに移動し、データを生成して、それをプラグインのサイトで入力して連携を完了します。
Google: https://developers.google.com/identity/protocols/oauth2/web-server に移動し、必要なデータの生成方法を確認します。
Microsoft: https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow に移動し、必要なデータの生成方法を確認します。
連携には、次のデータが必要となります。
スコープ - サービス プロバイダーでアプリケーションの共有を許可する、認証されるユーザー データのレベルです。例:
Google の場合、
https://mail.google.com/スコープを IMAP および POP3 に使用することをおすすめします。Microsoft の場合、https://outlook.office.com/IMAP.AccessAsUser.All or https://outlook.office.com/POP.AccessAsUser.All,およびoffline_access.の使用をおすすめします。
スコープの詳細については、Microsoft および Google のサイトで詳細を確認してください。
プロバイダーでのアプリケーション登録プロセスが完了したら、次の一意の資格情報を取得して、OAuth Server (Google など) で OAuth クライアント (Jira など) を認証します。これらをコピーし、OAuth 2.0 サイトの Jira に貼り付けます。
クライアント ID
クライアント シークレット
8. 設定を保存します。
9. [OAuth 2.0 統合] ページで [接続のテスト] をクリックして、接続が動作することを確認します。
メール サーバーに接続するために OAuth 2.0 を構成する場合、この受信メール サーバーの認証方式として連携を選択できます。[Jira 設定] > [システム] > [受信メール] に移動して、サーバーを構成します。
For details on how to reconfigure Jira Service Management's email channels to use your OAuth 2.0 integration, see Receiving requests by email.
OAuth 2.0 の設定の詳細
設定 | 注意 |
|---|---|
Resource provider | Google または Microsoft に該当する場合はそれを選択し、その他の連携では [Custom] を使用します。 |
名前 | この連携の一意の名前。 |
説明 | (オプショナル) |
クライアント ID | プロバイダーによって生成されたクライアント ID。プロバイダー側のアプリケーションの公開 ID です。 |
クライアント シークレット | プロバイダーによって生成されたクライアント シークレット。これは、アプリケーション (Jira など) とプロバイダーとの間で共有されるシークレットで、認証が安全であることを保証するものです。これは保存後に表示できるようになります。 |
スコープ | プロバイダーとやり取りするための必須 OAuth 2.0 スコープ。スコープの詳細をご覧ください。 |
認証エンドポイント | OAuth 2.0 を使用するための認証が開始する HTTPS URL。 |
トークン エンドポイント | トークンの更新リクエストが送信される HTTPS URL。OAuth 2.0 トークンには有効期限があるため、Jira は定期的にトークンを更新します。 |
リダイレクト URL | プロバイダー側に保存する必要があるリダイレクト URL。これにより、認証フローを Jira に戻して最初のプロセスを完了します。 |