以前に承認されたアプリケーションの OAuth 2.0 SAML ベアラーアサーションフロー
OAuth 2.0 SAML ベアラーアサーションフローでは、クライアントは接続アプリケーション経由で以前の認証を使用 (署名済み SAML 2.0 アサーションを指定) して、OAuth アクセストークンを要求できます。SAML アサーションに適用されるデジタル署名で、承認されたアプリケーションが認証されます。SAML アサーションは、ID プロバイダーが提供し、サービスプロバイダーが使用する XML セキュリティトークンです。サービスプロバイダーは、セキュリティ関連の目的でその内容を使用してアサーションの件名を識別します。
必要なエディション
| 使用可能なインターフェース: Salesforce Classic および Lightning Experience の両方 |
| 使用可能なエディション: すべてのエディション |
OAuth 2.0 SAML ベアラーアサーションフローは、OAuth 内の更新トークンのフローに似ています。SAML アサーションは OAuth トークンエンドポイントに POST されます。OAuth トークンエンドポイントは、アサーションを処理し、アプリケーションの前の承認に基づいて access_token を発行します。ただし、クライアントは refresh_token を使用または保存する必要はなく、client_secret をトークンエンドポイントに渡す必要もありません。
OAuth 2.0 SAML ベアラーアサーションフローの手順は次のとおりです。
- 接続アプリケーションを作成し、X509 証明書を登録します。この証明書はアプリケーションの非公開鍵に対応しています。接続アプリケーションを保存すると、コンシューマー鍵 (OAuth
client_id) が生成され、アプリケーションに割り当てられます。 - SAML アサーションを生成するアプリケーションを作成し、非公開鍵を使用してアプリケーションに署名します。
- フローを実装するために、接続アプリケーションは SAML ベアラーアサーションを Salesforce トークンエンドポイントに POST します。
- Salesforce は、接続アプリケーションに登録した証明書を使用して署名を検証します。また、アサーションの利用者、発行者、件名、および有効性も検証します。
- Salesforce は、アサーションが有効であり、ユーザーまたはシステム管理者がアプリケーションを以前に承認しているということを前提として、アクセストークンを発行します。
メモ このフローでは更新トークンはサポートされていません。
SAML ベアラーアサーションの作成
次のパラメーターを含む有効な SAML ベアラーアサーションを作成します。
| パラメーター | 説明 |
|---|---|
Issuer
|
この値は、開発者が証明書を登録した接続アプリケーションの OAuth client_id である必要があります。 |
Audience
|
値は https://login.salesforce.com または https://test.salesforce.com である必要があります。 |
Recipient
|
値は次のいずれかの URL である必要があります。
|
Subject NameID
|
この値は Salesforce ユーザーのユーザー名である必要があります。 |
SAML ベアラーアサーションは次のルールにも準拠している必要があります。
- アサーションは、RSA および SHA-1 または SHA-256 のいずれかを使用して、XML 署名仕様に従って署名する必要がある。
- SAML アサーションは http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer で規定されている一般的な形式に準拠する必要がある。
- トークンエンドポイントに POST する場合は、http://tools.ietf.org/html/rfc4648#page-7 の定義に従って base64url エンコードを使用してアサーションをエンコードする必要がある。
アサーションの例を次に示します。
<?xml version="1.0" encoding="UTF-8"?>
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_cd3649b3639560458bc9d9b33dfee8d21378409114655" IssueInstant="2013-09-05T19:25:14.654Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">3MVG9PhR6g6B7ps45QoRvhVGGMmR_DT4kxXzVXOo6TTHF3QO1nmqOAstC92 4qSUiUeEDcuGV4tmAxyo_fV8j</saml:Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
<ds:Reference URI="#_cd3649b3639560458bc9d9b33dfee8d21378409114655">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"><ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="ds saml"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>N8DxylbIeNg8JDO87WIqXGkoIWA=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
XV0lFJrkhJykGYQbIs0JBFEHdt4pe2gBgitcXrscNVX2hKGpwQ+WqjF8EKrqV4Q3/Q4KglrXl/6s
xJr6WOmxWtIQC4oWhSvVyfag34zQoecZeunEdFSMlnvPtqBVzJu9hJjy/QDqDWfMeWvF9S50Azd0
EhJxz/Ly1i28o4aCXQQ=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIICOzCCAaSgAwIBAgIGAR7RRteKMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVTMQswCQYD
VQQIEwJDQTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzENMAsGA1UEChMEUEFDUzENMAsGA1UECxME
U0ZEQzEPMA0GA1UEAxMGU0FNTDIwMB4XDTA5MDExMzE4MzUyN1oXDTE0MDExMTE4MzUyN1owYTEL
MAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRYwFAYDVQQHEw1TYW4gRnJhbmNpc2NvMQ0wCwYDVQQK
EwRQQUNTMQ0wCwYDVQQLEwRTRkRDMQ8wDQYDVQQDEwZTQU1MMjAwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAJNGcu8nW6xq2l/dAgbJmSfHLGRn+vCuKWY+LAELw+Kerjaj5Dq3ZGW38HR4BmZk
sG3g4eA1RXn1hiZGI1Q6Ei59QE/OZQx2zVSTb7+oIwRcDHEB1+RraYT3LJuh4JwUDVfEj3WgDnTj
E5vD46l/CR5EXf4VL8uo8T40FkA51AhTAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAehxggY6tBl8x
1SSvCUyUIHvxssAn1AutgZLKWuR1+FXfJzdVdE2F77nrV9YifIERUwhONiS82mBOkKqZZPL1hcKh
KSnFZN2iWmm1sspL73I/eAwVsOUj+bS3v9POo4ceAD/QCCY8gUAInTH0Mq1eOdJMhYKnw/blUyqj
Zn9rajY=
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">test@example.org</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:SubjectConfirmationData NotOnOrAfter="2013-09-05T19:30:14.654Z" Recipient="https://login.salesforce.com/services/oauth2/token"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2013-09-05T19:25:14.654Z" NotOnOrAfter="2013-09-05T19:30:14.654Z" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:AudienceRestriction xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Audience>https://login.salesforce.com/services/oauth2/token</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2013-09-05T19:25:14.655Z" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:AuthnContext xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
アクセストークンの要求
接続アプリケーションは SAML ベアラーアサーションを Salesforce トークンエンドポイントに POST します。
トークン要求の例を次に示します。
POST /services/oauth2/token HTTP/1.1
Host: login.salesforce.com
Content-Type: application/x-www-form-urlencoded
grant_type= urn:ietf:params:oauth:grant-type:saml2-bearer&
assertion=PHNhbWxwOl...[omitted for brevity]...ZT
POST するときは、次のパラメーターを指定する必要があります。
重要 OAuth インテグレーションを開発するときは、常に機密情報を POST 要求の本文または要求ヘッダーで渡します。機密情報を渡すために URL クエリ文字列で GET パラメーターを使用しないでください。機密情報には、ユーザー名、パスワード、OAuth トークン、クライアントの秘密、個人識別情報が含まれますが、これらに限定されません。セキュリティのベストプラクティスについての詳細は、『Secure Coding Guide (セキュアコーディングガイド)』の「Storing Sensitive Data (機密データの保存)」を参照してください。
| パラメーター | 説明 |
|---|---|
grant_type
|
接続アプリケーションが要求する OAuth 2.0 許可種別。値は urn:ietf:params:oauth:grant-type:saml2-bearer である必要があります。 |
assertion
|
SAML ベアラーアサーション。次の定義に従って base64url を使用してエンコードされます: http://tools.ietf.org/html/rfc4648#page-7。 |
次の標準パラメーターを含めることもできます。
| パラメーター | 説明 |
|---|---|
format
|
要求のヘッダーに含まれていない場合、予測される戻り形式を指定できます。
|
scope
|
SAML ベアラーアサーションフローで範囲を指定することはできません。代わりに、このパラメーターの値は、前のアクセストークンから発行された範囲の組み合わせになっています。 |
Salesforce によるアクセストークンの付与
要求の確認後、Salesforce からクライアントにレスポンスが送信されます。OAuth 2.0 SAML ベアラートークンフローのトークン応答は、authorization_code フローと同じ形式に従っていますが、refresh_token が発行されることはありません。
メモ
OAuth 2.0 JWT ベアラーおよび SAML アサーションベアラーフロー要求は、更新トークンを含むユーザーの以前のすべての承認を確認します。一致する承認が見つかった場合、Salesforce は承認された範囲の値を組み合わせます。次に、Salesforce はアクセストークンを発行します。更新トークンまたは承認された使用可能な範囲を含んでいた以前の承認が見つからない場合、要求は未認証として失敗します。
関連項目:
この記事で問題は解決されましたか?
ご意見をお待ちしております。
