--- title: "Ncloud Single Sign-On とは" slug: "sso-integration-info" updated: 2026-09-17T09:23:26Z published: 2026-09-17T09:23:26Z canonical: "guide.ncloud-docs.com/sso-integration-info" --- > ## Documentation Index > Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt > Use this file to discover all available pages before exploring further. # Ncloud Single Sign-On とは Classic/VPC環境で利用できます。 Ncloud Single Sign-Onを連携する方法を学習する前に、Ncloud Single Sign-Onの連携に必要ないくつかの重要な概念を説明します。ここで説明する主な概念は、次の通りです。 - [OAuth 2.0の定義](/docs/ja/sso-integration-info#OAuth20%EC%A0%95%EC%9D%98) - [OAuth 2.0のロール](/docs/ja/sso-integration-info#OAuth20%EC%97%AD%ED%95%A0) - [OpenID Connect](/docs/ja/sso-integration-info#OpenIDConnect) - [Access Token](/docs/ja/sso-integration-info#AccessToken) - [Refresh Token](/docs/ja/sso-integration-info#RefreshToken) - [ID Token](/docs/ja/sso-integration-info#IDToken) - [OAuth 2.0の認証フロー](/docs/ja/sso-integration-info#OAuth20%EC%9D%B8%EC%A6%9D%ED%94%8C%EB%A1%9C%EC%9A%B0) - [SAML 2.0の定義](/docs/ja/sso-integration-info#SAML20%EC%A0%95%EC%9D%98) - [SAML 2.0のロール](/docs/ja/sso-integration-info#SAML20%EC%97%AD%ED%95%A0) ## OAuth 2.0の定義 OAuth 2.0は、権限付与のためのオープン型認証プロトコルです。OAuth 2.0はリソースサーバにアクセスできる権限を、リソースを所有しているユーザーの代わりにアプリケーションに委任します。 ## OAuth 2.0のロール OAuth 2.0で定義するロールは次の通りです。 | ロール | 定義 | | --- | --- | | Resource Owner | 保護されているリソースに対するアクセス資格を承認できるユーザー。Resource Ownerは保護されているリソースを所有し、アクセス権を持つ Clientが Resource Ownerに代わってリソースにアクセス。 | | Client | Resource Ownerの代わりに認証情報である Access Tokenを発行され、保護されているリソースにアクセスするアプリケーション | | Identity Provider | Resource Ownerを認証し、Resource Ownerの権限承認により、Clientに Access Tokenを発行するサーバ | | Resource Server | Clientが Access Tokenを利用してリソースにアクセスする時、アクセスのリクエストを確認およびレスポンスし、保護されているリソースを提供するサーバ | ## OpenID Connect OpenID Connectは、OAuth 2.0ベースで Token発行時に IdPでユーザー情報を持つ ID Tokenを発行するプロトコルです。 ## Access Token Access Tokenは、Clientが保護されているリソースにアクセスするため、権限が許可されたことを示す認証情報であり、IdPで発行された文字列です。Clientは、Access Tokenを利用して Resource Serverにアクセスできます。 ## Refresh Token Refresh Tokenは、IdPで発行される Tokenで、期限切れの Access Tokenの期限を延長して発行する場合または同じか狭い Scopeの追加 Access Token発行時に使用されます。Clientが Refresh Tokenを含め、Access Token発行 APIを IdPに送ると、偽造または改ざんされていないかを確認してから Access Tokenを発行します。 ## ID Token ID Tokenは、ユーザー情報を持つ JWTタイプの Tokenで、Token発行リクエスト時、`scope`に `id_token`を含む場合、Access Tokenと一緒に IdPで発行されます。 ## OAuth 2.0の認証フロー OAuth 2.0認証プロトコルのフローは次の通りです。 - [Authorization Codeフロー](/docs/ja/sso-integration-info#AuthorizationCode%ED%94%8C%EB%A1%9C%EC%9A%B0) - [PKCEフロー](/docs/ja/sso-integration-info#PKCE%ED%94%8C%EB%A1%9C%EC%9A%B0) - [Implicitフロー](/docs/ja/sso-integration-info#Implicit%ED%94%8C%EB%A1%9C%EC%9A%B0) 参考 ここでは Resource Ownerがフローを開始し、Clientが保護されているリソースにアクセスするまでの OAuth 2.0のフローについて説明します。フローに使用される APIに関する詳細は、[Ncloud Single Sign-On連携 API](/docs/ja/sso-integration-api)をご参照ください。 ### Authorization Codeフロー Authorization Codeフローは最も一般的な認証フローであり、説明は次の通りです。 ![sso-integration-info_scenario1_ko](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/sso-integration-info_scenario1_ja.png?sv=2026-02-06&spr=https&st=2026-10-30T21%3A34%3A23Z&se=2026-10-30T22%3A34%3A23Z&sr=c&sp=r&sig=7ysk4y9lSpOp4%2FY88TaVpoHZkoX1j%2Bw%2BUhZTivOzqJM%3D) 1. Resource Ownerがログインボタンをクリックしてフローを開始します。 2. Clientが保護されているリソースにアクセスするため、レスポンス方式をコードに設定してから権限付与をリクエストします。 3. IdPが Resource Ownerに個人情報の提供に対する同意ページとログインページを送信します。 4. Resource Ownerが同意とログインにて権限付与を承認します。 5. IdPが Authorization codeを Clientに送信します。 6. Clientが Authorization codeを利用して IdPに Access Tokenの発行をリクエストします。 7. IdPで Authorization codeを確認してから Tokenを発行します。 8. Access Tokenを持つ Clientが Resource Serverにアクセスして保護されているリソースをリクエストします。 9. Resource Serveがリクエストされたリソースを Clientに送信します。 ### PKCEフロー PKCEフローは、Authorization Codeフローで行うときにセキュリティを強化する機能であり、PKCEを含むフローに対する説明は次の通りです。 ![sso-integration-info_scenario2_ko](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/sso-integration-info_scenario2_ja.png?sv=2026-02-06&spr=https&st=2026-10-30T21%3A34%3A23Z&se=2026-10-30T22%3A34%3A23Z&sr=c&sp=r&sig=7ysk4y9lSpOp4%2FY88TaVpoHZkoX1j%2Bw%2BUhZTivOzqJM%3D) 1. Resource Ownerがログインボタンをクリックしてフローを開始します。 2. Clientが Code Verifierと Code Challengeを作成します。 3. 権限付与のリクエスト時に Clientが作成した Code Challengeと Code Challenge Methodを一緒に送信すると、その値が IdPに保存されます。 4. IdPが Resource Ownerに個人情報の提供に対する同意ページとログインページを送信します。 5. Resource Ownerが同意とログインにて権限付与を承認します。 6. IdPが Authorization codeを Clientに送信します。 7. Clientが Code Verifierと Authorization codeを含めて IdPに Access Tokenの発行をリクエストします。 8. IdPが保存された Code Challengeと Code Verifierを比較して一致有無を確認します。 9. 2つの値が一致する場合、IdPから Access Tokenを発行します。 10. Access Tokenを持つ Clientが Resource Serverにアクセスして保護されているリソースをリクエストします。 11. Resource Serveがリクエストされたリソースを Clientに送信します。 ### Implicitフロー Implicitフローは、認証情報を安全に保存・管理することが難しい Client環境に適しているフローで、説明は次の通りです。 ![sso-integration-info_scenario3_ko](https://cdn.document360.io/6998976f-9d95-4df8-b847-d375892b92c2/Images/Documentation/sso-integration-info_scenario3_ja.png?sv=2026-02-06&spr=https&st=2026-10-30T21%3A34%3A23Z&se=2026-10-30T22%3A34%3A23Z&sr=c&sp=r&sig=7ysk4y9lSpOp4%2FY88TaVpoHZkoX1j%2Bw%2BUhZTivOzqJM%3D) 1. Resource Ownerがログインボタンをクリックしてフローを開始します。 2. Clientがレスポンス方式を Tokenに設定してから権限付与をリクエストします。 3. IdPが Resource Ownerに個人情報の提供に対する同意ページとログインページを送信します。 4. Resource Ownerが同意とログインにて権限付与を承認します。 5. IdPから Access Tokenを発行します。 6. Access Tokenを持つ Clientが Resource Serverにアクセスして保護されているリソースをリクエストします。 7. Resource Serveがリクエストされたリソースを Clientに送信します。 ## SAML 2.0の定義 SAML 2.0は、ウェブベースのオープン型認証プロトコルです。アプリケーション間でユーザー認証と権限情報をやり取りする際に使用される標準情報形式である SAML 2.0により、IdPと SPがユーザーの情報を安全に交換して認証することができます。 ## SAML 2.0のロール SAML 2.0で定義するロールは、次の通りです。 | ロール | 定義 | | --- | --- | | Service Provider (SP) | サービスを提供する主体。主に SSOユーザーが利用しようとするアプリケーションやサービスを意味し、Identity Provider(IdP)にユーザーの認証情報をリクエスト | | Identify Provider (IdP) | Service Provider(SP)がリクエストしたユーザーの認証情報を検証し、Service Provider(SP)にユーザーの認証情報を提供するシステム | | SAML Request | Identity Provider(IdP)と Service Provider(SP)間で認証情報を交換するためのリクエストメッセージを意味し、SAML Assertion(認証情報)を作成するための情報を含む | | SAML Response | Identity Provider(IdP)と Service Provider(SP)間で認証情報を交換するためのレスポンスメッセージを意味し、SAML Assertion(認証情報)およびその他必要なメタデータを含む。これにより、IdPがユーザーの認証情報を検証した後、SPに認証結果を提供 | | SAML Assertion | Id、認証時間、認証方法などユーザーの認証情報を含む XML文書を Identity Provider(IdP)から Service Provider(SP)に送信。これにより、SPはユーザーの認証を検証 | | ACS URL | Service Provider(SP)が Assertion Consumer Service(ACS)を提供するために使用する URL |