Loading
Identifisere brukerne og administrere tilgang
Konfigurere flyten for tokenutveksling

Du er her:

  1. Salesforce Hjelp
  2. Dokumenter
  3. Identifisere brukerne og administrere tilgang

Konfigurere flyten for tokenutveksling

Enkelte brukstilfeller krever at du integrerer Salesforce med en ekstern identitetsleverandør sammen med flere apper og mikrotjenester. Bruk OAuth 2.0-tokenutvekslingsflyten til å forenkle disse integrasjonene. Med denne flyten bytter du tokener fra en ekstern identitetsleverandør for Salesforce-tokener.

Nødvendige utgaver

Tilgjengelig i Enterprise, Performance, Unlimited og Developer Edition

Du er for eksempel vert for en kundeportal utenfor Salesforce-plattformen. Til å gi pålogging og registrering til kundene bruker du en identitetsleverandør. Når kundene er logget på, får de tilgang til data fra en rekke bedriftstjenester, inkludert nettapper og mikrotjenester. For å autorisere portalen til å gi brukere tilgang til dataene sine, godtar alle disse forretningstjenestene tilgangstokener fra identitetsleverandøren.

Du bruker Salesforce til å spore kunders kundestøttesaker, og du vil gi brukere en måte å få tilgang til sakene deres på i portalen din. Ved å konfigurere Salesforce til å godta tokener fra identitetsleverandøren din, kan du enkelt tilpasse Salesforce til integrasjonsmønsteret ditt. Ved å bruke tokenutvekslingsflyten validerer Salesforce identitetsleverandørens tokener, tilordner dem til en Salesforce-bruker og utsteder Salesforce-tokener slik at brukere får tilgang til dataene sine i portalen.

Her er en trinnvis oversikt over tokenutvekslingsflyten.

Sekvensdiagram som viser trinnene i tokenutvekslingsflyten

Sluttbrukere ber om tilgang til Salesforce-data (1)

En sluttbruker blir logget på appen. De ber om tilgang til beskyttede Salesforce-ressurser. De kan for eksempel klikke på en knapp for å vise sakene sine.

App har et gyldig token (2)

Når sluttbrukeren logget seg på, mottok de ett eller flere tokener fra identitetsleverandøren. De mottar for eksempel et tilgangstoken og et oppdateringstoken. For å få tilgang til Salesforce-data kan appen utveksle ett av disse tokenene. Salesforce godtar disse tokentypene.

  • tilgangstokener
  • Oppdateringstokener
  • JSON-netttokener (JWT-er)
  • SAML-deklarasjoner
  • ID-tokener

App ber om en utveksling for et Salesforce-token (3)

For å få et Salesforce-token sender appen en POST-forespørsel til sluttpunktet /services/oauth2/token i Mitt domene-URL-adressen for pålogging eller URL-adressen til Experience Cloud-nettstedet.

Viktig
Viktig Når du utvikler OAuth-integrasjoner, overfører du alltid sensitiv informasjon i hoveddelen av en POST-forespørsel eller i et forespørselshode. Ikke bruk GET-parametere i URL-spørrestrengen til å overføre sensitiv informasjon. Sensitiv informasjon inkluderer, men er ikke begrenset til brukernavn, passord, OAuth-tokener, klienthemmeligheter og eventuell personlig identifiserbar informasjon. Hvis du vil ha mer informasjon om gode fremgangsmåter for sikkerhet, kan du se Lagre sensitive data i Secure Coding Guide.

Forespørselen støtter ett hode.

Tokenforespørselshode
Hode Obligatorisk? Beskrivelse
Uvid-Hint Nei. Hvis du implementerer gjestebrukerflyten i appen, kan du eventuelt bruke dette hodet til å overføre en unik besøks-ID (UVID) som er knyttet til en gjestebrukers identitet. Bruk UVID til å overføre kontekstinformasjon fra en gjestebrukerøkt, som brukerens preferanser for informasjonskapsler, til en navngitt brukerøkt.

Inneholder UVID, en versjon 4-universelt unik identifikator (UUID) som identifiserer ukjente besøkende. Send UVID-koden som en ren verdi, eller send et JWT-basert tilgangstoken med et UVID festet i den.

Hvis du vil sende UVID som en ren verdi, inkluderer du et UVID-prefiks slik at forespørselen blir formatert som Uvid-Hint: UVID <UVID value>.

Hvis du vil sende et JWT-basert tilgangstoken med en UVID, inkluderer du et JWT-prefiks før verdien, for eksempel Uvid-Hint: JWT <access token containing UVID>.

Inkluder disse parameterne i forespørselen.

Tokenforespørselstekstparametere
Parameter Obligatorisk? Beskrivelse
grant_type Ja.

OAuth 2.0-metoden som appen bruker til å be om tilgangstokenet. Tokenutvekslingsflyten støtter disse verdiene.

  • For de fleste brukstilfeller, brukurn:ietf:params:oauth:grant-type:token-exchange.
  • For hybridmobilapper bruker du urn:ietf:params:oauth:grant-type:hybrid-token-exchange.
subject_token Ja. Tokenet som er utstedt av identitetsleverandøren. Den maksimale lengden er 10 000 tegn.
subject_token_type Ja.

Typen token utstedt av identitetsleverandøren. Flyten støtter disse tokentypene.

  • urn:ietf:params:oauth:token-type:access_token: Et OAuth 2.0-tilgangstoken.
  • urn:ietf:params:oauth:token-type:refresh_tokenEt OAuth 2.0 oppdateringstoken.
  • urn:ietf:params:oauth:token-type:id_token: Et OpenID Connect-ID-token.
  • urn:ietf:params:oauth:token-type:saml2: En base64 URL-kodet SAML 2.0-deklarasjon.
  • urn:ietf:params:oauth:token-type:jwt: Et hvilket som helst token som er formatert som et JWT.
client_id Ja. Forbrukernøkkelen til den tilkoblede appen eller den eksterne klientappen.
client_secret

Det avhenger av innstillingene for den tilkoblede appen eller den eksterne klientappen.

For tilkoblede apper aktiverer du Kreve hemmelighet for tokenutvekslingsflyt i innstillingene for tilkoblede apper for å kreve en client_secret.

For eksterne klientapper angir du isSecretRequiredForTokenExchange-feltet i metadatatypen ExtlClntAppGlobalOauthSettings til true.

 Forbrukerhemmeligheten for den tilkoblede appen eller den eksterne klientappen. Vi anbefaler at du sender en forbrukerhemmelighet bare hvis appen har en privat serverdel der den kan holde hemmeligheten sikker. For offentlige klienter som ikke har en privat serverdel, som mobilapper og apps med én side, anbefaler vi ikke å sende en hemmelighet fordi den kan bli lekket gjennom nettleseren.
scope Nei.

Tillatelser som definerer hvilke typer beskyttede ressurser en tilkoblet app kan få tilgang til. Verdiene som du sender i denne forespørselen, må samsvare med eller være et delsett av omfangene som er tildelt den tilkoblede appen eller den eksterne klientappen.

Hvis du vil ha mer informasjon om hvert omfang og dets formål, kan du se OAuth-tokener og -omfang.
token_handler Nei, men det anbefales sterkt. Hvis du ikke inkluderer denne parameteren, bruker Salesforce standardbehandleren. Du definerer en standardbehandling ved å bruke isDefault-feltet i OauthTokenExchHandlerApp-metadatatypen. Du må ha minst én standardbehandling. Navnet på Apex som brukes til å validere tokenet og tilordne det til en Salesforce-bruker.

Her er et eksempel på en tokenforespørsel som inneholder et tilgangstoken.

POST /services/oauth2/token? HTTP 1.1
Host: MyDomainName.my.site.com
Uvid-Hint: UVID abcd-1234-efgh

grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
subject_token=*************&
subject_token_type=urn:ietf:params:oauth:token-type:access_token&
client_id=***********&
client_secret=************&
scope=web&
token_handler=MyTokenHandler

Salesforce OAuth-kjøretid fullfører første validering (4)

Salesforces OAuth-kjøretid mottar forespørselen og kjører den gjennom en første validering. Valideringen er basert på disse kravene.

  • Den tilkoblede appen eller den eksterne klientappen må være aktivert for tokenutvekslingsflyten. Se Integrere en app for tokenutvekslingsflyten.
  • subject_token_type i forespørselen må være aktivert for tokenutvekslingsbehandleren. Hvis du vil aktivere en behandler for en tokentype, angir du det tilsvarende feltet i behandlerens OauthTokenExchangeHandler-metadatadefinisjon til true.
    subject_token_type-verdiOauthTokenExchangeHandler-felt
    urn:ietf:params:oauth:token-type:access_token isAccessTokenSupported
    urn:ietf:params:oauth:token-type:refresh_token isRefreshTokenSupported
    urn:ietf:params:oauth:token-type:id_token isIdTokenSupported
    urn:ietf:params:oauth:token-type:saml2 isSaml2Støttes
    urn:ietf:params:oauth:token-type:jwt isJwtSupported
  • Hvis forespørselen inkluderer en client_secret, må den samsvare med forbrukerhemmeligheten til den tilkoblede appen eller den eksterne klientappen.
  • Hvis forespørselen inkluderer en token_handler, må organisasjonen ha en støttet Apex-tokenutvekslingsbehandler som samsvarer med navnet i forespørselen.
  • Tokenutvekslingsbehandleren må være aktivert, som betyr at isEnabled-feltet i OauthTokenExchangeHandler-metadata-definisjonen må være satt til true.

Hvis forespørselen oppfyller disse første kravene, sender Salesforce tokenet fra den eksterne identitetsleverandøren til Apex.

Apex validerer tokenet (5)

Apex mottar identitetsleverandørtokenet og validerer det med din tilpassede valideringslogikk. Hvordan du vil validere tokenet er helt opp til deg.

(Valgfritt) Apex ringer opp identitetsleverandøren for validering (6)

Avhengig av valideringskravene kan du eventuelt konfigurere behandleren til å kalle opp identitetsleverandøren. Hvis tokenet er ugjennomsiktig, eller hvis du vil validere det i sanntid, kaller du opp tokenanalyse- eller Brukerinformasjon-endepunktet for den eksterne identitetsleverandøren.

Apex Handler tilordner tokenet til et Salesforce-emne (7)

Apex identifiserer tokens emne, som er sluttbrukeren som det ble utstedt til, og tilordner det til et Salesforce-emne.

(Valgfritt) Apex ringer opp til identitetsleverandøren for brukerinformasjon (8)

For å få nok informasjon til å opprette et emne, eller for å få mer informasjon om et innkommende emne, kan du eventuelt konfigurere behandleren til å kalle opp identitetsleverandøren eller et annet eksternt system.

Apex finner eller konfigurerer en bruker (9)

Hvis behandleren finner en bruker basert på data fra tokenet eller fra et eksternt oppkall, returneres brukeren.

Hvis feltet isUserCreationAllowed er satt til true i behandlerens OauthTokenExchangeHandler-metadatadefinisjon, konfigurerer behandleren et nytt brukerobjekt og returnerer det til Salesforce. Denne handlingen oppretter faktisk ikke brukeren – i stedet returneres Bruker-objektet til Salesforce for automatisk innsetting.

Hvis du vil ha mer informasjon om hvordan du tilpasser behandleren for å validere tokener og tilordne emner, kan du se Token Exchange-behandlingsvalidering og emnetilordning i Apex Developer Guide.

Salesforce OAuth-kjøretid fullfører brukertilordning (10)

Salesforce OAuth-kjøretiden kontrollerer om behandleren har returnert en bruker. I så fall bekrefter den om brukeren finnes, og fullfører tilordningen. Hvis brukeren ikke finnes, og hvis behandleren er konfigurert til å konfigurere brukere, setter Salesforce automatisk inn brukeren på vegne av tokenutvekslingsbehandleren.

Salesforce OAuth-kjøretidsrespons for retur av token (11)

Salesforce returnerer et svar som inneholder et Salesforce-tilgangstoken og eventuelle andre tokener eller parametere som du har bedt om, inkludert oppdateringstokener, ID-tokener og hybridtokener. Tilgangstokenet kan være opakt eller JWT-basert avhengig av innstillingene for den tilkoblede appen eller den eksterne klientappen.

Hvis du har sendt en UVID i tokenforespørselen, sendes den også gjennom flyten. For å oppnå en ugjennomsiktig tokensvar vises UVID-en på endepunktet services/oauth2/userinfo i Mitt domene-URL-adressen for pålogging eller URL-adressen til Experience Cloud-nettstedet. For et JWT-basert tokensvar slås UVID inn i det nye tilgangstokenet.

App mottar svar (12)

Appen mottar tokensvaret, inkludert tilgangstokenet og andre tokener og parametere. Her er et eksempel på et tokensvar.

{
    "access_token":"*******************",
    "signature":"ts6wm/svX3jXlCGR4uu+SbA04M6qhD1SAgVTEwZ59P4=",
    "scope":"openid api",
    "id_token":"XXXXXX",
    "instance_url":"https://MyDomainName.my.salesforce.com",
    "id":"https://MyDomainName.my.salesforce.com/id/00Dxxxxxxxxxxxx/005xxxxxxxxxxxx",
    "token_type":"Bearer",
    "issued_at":"1667600739962"
}

Sluttpunkt for appoppringingsbrukerinformasjon (13)

Hvis det er nødvendig for å fullføre brukerpåloggingen, kan appen kalle opp sluttpunktet /services/oauth2/userinfo i Mitt domene-URL-adressen for pålogging eller URL-adressen til Experience Cloud-nettstedet. Hvis du for eksempel har sendt en UVID i tokenforespørselen, og Salesforce returnerte et svar med et opakt tilgangstoken, kaller du opp sluttpunktet Brukerinformasjon for å hente UVID.

Appber om tilgang til Salesforce-data (14)

Nå som appen har et Salesforce-tilgangstoken, sender den en godkjent forespørsel til en beskyttet Salesforce-ressurs for å hente brukernes data.

Sluttbruker har tilgang til Salesforce-data (15)

Hvis forespørselen er vellykket, kan sluttbrukeren få tilgang til sine Salesforce-data i appen. Fra brukerens perspektiv klikket de bare på en knapp og så dataene sine uten å bli bedt om å logge seg på eller godkjenne tilgang.

 
Laster
Salesforce Help | Article