OAuth 2.0 SAML-bärarkontrollflöde för tidigare auktoriserade appar
Med OAuth 2.0 SAML-bärarkontrollflöde kan en klient—via en ansluten app—använda tidigare auktorisering genom att tillhandahålla en signerad SAML 2.0-kontroll för att begära en OAuth-åtkomsttoken. Den digitala signaturen som tillämpas till SAML-kontroll autentiserar den auktoriserade appen. En SAML-kontroll är en XML-säkerhetstoken som utfärdas av en identitetsleverantör och konsumeras av en tjänsteleverantör. Tjänsteleverantören förlitar sig på dess innehåll för att identifiera kontrollens ämne av säkerhetsskäl.
Versioner som krävs
| Tillgängliga i: både Salesforce Classic och Lightning Experience |
| Tillgängliga i: Alla versioner |
OAuth 2.0 SAML-bärarkontrollflödet liknar flödet för en uppdateringstoken inom OAuth. SAML-kontrollen skickas till OAuth-tokenslutpunkten, som i sin tur bearbetar kontrollen och utfärdar ett access_token baserat på ett tidigare godkännande av appen. Klienten behöver dock inte ha eller lagra en refresh_token och behöver inte heller skicka en client_secret till tokenslutpunkten.
OAuth 2.0 SAML-bärarkontrollflödet innefattar dessa steg.
- Skapa en ansluten app och registrera ett X509-certifikat. Detta certifikat motsvarar appens privata nyckel. När den anslutna appen sparas skapas en konsumentnyckel (OAuth
client_id) som tilldelas appen. - Skriv en app som skapar en SAML-kontroll och signera med den privata nyckeln.
- För att implementera flödet publicerar den anslutna appen SAML-bärarkontrollen till Salesforce-tokenslutpunkten.
- Salesforce validerar signaturen med certifikatet som registrerats för den anslutna appen. Tokenslutpunkten validerar även kontrollens målgrupp, utfärdare, ämne och giltighet.
- Om kontrollen är giltig och användaren eller administratören tidigare har auktoriserat appen utfärdar Salesforce en åtkomsttoken.
Anteckning Detta flöde har inte stöd för uppdateringstokens.
Skapa en SAML-bärarkontroll
Skapa en giltig SAML-bärarkontroll som inkluderar dessa parametrar.
| Parameter | Beskrivning |
|---|---|
Issuer
|
Värdet måste vara den anslutna appens OAuth-client_id som utvecklaren registrerade sitt certifikat för. |
Audience
|
Värdet måste vara https://login.salesforce.com eller https://test.salesforce.com. |
Recipient
|
Värdet måste vara en av dessa URL:er.
|
Subject NameID
|
Detta värde måste vara användarnamnet för Salesforce-användaren. |
SAML-bärarkontrollen måste även följa dessa regler.
- Giltigheten måste skrivas under enligt XML Signaturspecification, med RSA och antingen SHA-1 eller SHA-256.
- SAML-kontrollen måste överensstämma med de allmänna formatregler som specificeras här: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer.
- När kontrollen skickas till tokenslutpunkten måste den kodas med base64url-kodning enligt definitionen här: http://tools.ietf.org/html/rfc4648#page-7
Här är ett exempel på en kontroll.
<?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>
Begär en åtkomsttoken
Den anslutna appen publicerar en SAML-bärarkontroller till Salesforce-tokenslutpunkten.
Här är ett exempel på en tokenbegäran.
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
Vid publicering måste dessa parametrar tillhandahållas.
| Parameter | Beskrivning |
|---|---|
grant_type
|
Den OAuth 2.0 grant type som den anslutna appen begär. Värdet måste vara urn:ietf:params:oauth:grant-type:saml2-bearer |
assertion
|
SAML-bärarkontrollen, kodad med base64url enligt definitionen här: http://tools.ietf.org/html/rfc4648#page-7. |
Du kan även inkludera dessa standardparametrar.
| Parameter | Beskrivning |
|---|---|
format
|
Om det inte inkluderas i begärans sidhuvud kan du specificera det förväntade returformatet. Parametern
|
scope
|
Det går inte att specificera omfattningar i ett SAML-bärarkontrollflöde. Istället är värdet för denna parameter en kombination av omfång från tidigare åtkomsttokens. |
Salesforce beviljar en åtkomsttoken
Efter att begäran är verifierad så skickar Salesforce ett svar till klienten. Tokensvar för OAuth 2.0 SAML-bärartokenflödet följer samma format som authorization_code, även om ett refresh_token aldrig utfärdas.
