breadcrumbDescription
Brug og validering af aktivtokener
Når Salesforce udsteder et aktivtoken, præsenterer enheden sine data eller begivenhed for din backendservice sammen med aktivtokenet. Din backendservice validerer aktivtokenet og bestemmer, om enheden er autoriseret for den ønskede handling. Almindelige metoder til sikring af kommunikation mellem enheden og din backendtjeneste er bearertokensekvensen og JWT-bearertokenudvekslingssekvensen. Brug open-source-standardbiblioteker til at validere aktivtoken-JWT'er.
EditionsHeading
| Tilgængelig i: både Salesforce Classic (ikke tilgængelig i alle organisationer) og Lightning Experience |
| Tilgængelig i: Alle versioner |
Brug aktivtokener i bearertokensekvensen
Bearertokensekvensen er en enkel, fælles metode for klienten at præsentere aktivtokenet i godkendelsessidehovedet som et OAuth-token: Authorization: Bearer JWT. Der genereres et token for hvert kald. Bearertokensekvensen er den enklere tilgang.
Følgende diagram viser bearertokenudvekslingen for en Oplevelseskonstruktør-lokalitet.
Her er der et eksempel på bearertokenudveksling for en Oplevelseskonstruktør-lokalitet.
POST /ingestapi HTTP/1.1
Host: api.devicebackend.com
Content-Type: application/json
Authorization: Bearer
eyJraWQiOiJBc3NldHMiLCJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdWQiOlsiaHR0cDovL2xvY2F saG9zdDo1MDAwIl0sIm5iZiI6MTQ1MjQ5MTc4OSwiaXNzIjoiaHR0cHM6Ly9hc3NldGlkLWRldmVsb3Blci1 lZGl0aW9uLm5hMS1ibGl0ejAzLnNvbWEuZm9yY2UuY29tIiwiY25mIjp7Imp3ayI6eyJrdHkiOiJSU0EiLCJ lIjoiQVFBQiIsImtpZCI6ImRldmljZWtleSIsIm4iOiJqY3YxZndyQnFZa2NzeFBTSjR2cG03Yjc4cXZpTjl 3OXVieF9sUUhV0lEWDdOYUt2UGxQNmxGUDF3MHJZci0xelN1c0JGakxLeGhrVmJsSGRER3ZldDN4NUJmZ1p3 NXducmt3N1ZqYjZyeWNMNWhGOVBuOXU2Rndla3NXN0l4YnBqRVZQbEltT1I4Mkg0LXdOV053dzFCZ2xrVlJF OTdsUFVMQlc0WlRwbkZiTW84a2owVVE0S2d2Ri13UnN1dmcwOVhaa1FPdnF4dFdHQ0pJUzJZSHoxUEw1cEll TXFwMFlwSkxWZ3g1QXZHTDVHNXl0bVprX3JfZnl1QXJ4TGstdWZXNE1qSkw2Rmo4dzFLYnZ6YXhlMWlDbGQ tdXRsd2JUWmtfN0daSUtsbVR4d1JGZkJqVWM4VzRsbFJoMDdFUXI0cThpNHVYeEJaQ3pEWjcyQWxXWHcifX0 sImlkIjoiMDViRDAwMDAwMDAwMDU2IiwiZXhwIjoxNDUzMDEwMTc1LCJhaWQiOiIwMmlEMDAwMDAwMTZHTVI iLCJkaWQiOiI2YWM5YmMyMi0yYTQxLWI4NWEtYWY3Ni1jMTJlOWUzYmY4YmMifQ.LhGF8nkJVd3soE 7UjLujjTVIjMzbzwicWpJ6tLlFScX7Yc45nzv1ccDB2UHHj2R5aEZT4K8gfLAD8AHWHErhwVmHLkTeqtXok8 a-S1dg QW_7-STybWl3Bf2xHXomm9ZdvL406UaZMOdCNrNDSqAZn0kgupo3orzkCC3YLCes1nc4iFIMKXbWCeRiEkGo Przx09PnJqUA9nz74nyKo3-NhpZvy6o-qxAryeibUeOfrtG8wvbnjjbNEDukS-GU0rZTcW9KABboCT 13DLFM 5caFofNgcKE3W67zlJIcSAEgOSVNVoiFYwSlTvWiyxMIMabEOd8usAfwnIKk1XUYnuNG0w
{"some": "data"}
Brug aktivtokener i JWT-bearertokensekvensen
I JWT-bearertokenets udvekslingssekvens genererer klienten anmodningen, kalder målsystemet for at udveksle dets aktivtoken og modtager et OAuth-token, som det præsenterer for efterfølgende kald. Denne anvendelse kan blive mere effektiv, hvis du arrangerer en række kald, eller hvis målet er sessionsorienteret. Et token genereres og udveksles pr. session på målet ved brug af JWT Bearertokenprofilen for den OAuth 2.0-klientgodkendelse, der er defineret af RFC 7523-specifikationen.
Følgende diagram viser JWT-bearertokenudvekslingen for en Oplevelseskonstruktør-lokalitet.
I dette eksempel anmoder du først om et adgangskoten:
POST /oauth2/token HTTP/1.1
Host: login.devicebackend.com
Content-Type: application/x-w w-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange&subject_
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=ey
JraWQiOiIxOTgiLCJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJhdF9oYXNoIjoiT1c2ajJfNF
pqcmU4cGFkREpYdEZEQSIsInN1YiI6Imh0dHBzOi8vbG9naW4uc2FsZXNmb3JjZS5jb20vaWQvMDB
EMzAwMDAwMDAwbWx4RUFBBLzAwNTMwMDAwMDAwZ0tWOEFBTSIsImF1ZCI6IjNVkc5OU94VHlFTUNR
M2dYdVgzMWx5c1gzUlFQNC5WajNFVnpsTXNWYnhGdlVlN1ZqWjBXY2pXdkdsQVU3QlBKRlpCU3lCR
1BpR3lIaG9qWjJCRTMiLCJpc3MiOiJodHRwwczovL2xvZ2luLnNhbGVzZm9yY2UuY29tIiwiZXhwI
joxNDUxNTExNjU2LCJpYXQiOjE0NTE1MTE1MzZ9.ervvV9H89ODomiXekq0_6SVkgxZkQGaJ8nKXj
t3VSCB46e7YiHN3lDg9BXFfT8NdtipCHpHNQCAJ38R-II_txVb1U-QE598sNK5aHVGNkyzoQnPIsL
VPFDZrWCi1v4FDGBfxtckiGWw_bN1x_FYO0qnLwaD5Fdz7kNdi_Xujvsf63tdW-nfWUoyld6-htu5
eDI3cergGz3itaYyJHpPF7od11ff6O2cW9YUVXQaOF1vcOPK1R23QTlxkPm5rNT2NnWyEWEm_v4Fj
TbqItNK5hgRQO6DYG1xmCkC6V1AD7AVIRbTF99-9f_c5t9BDR1x1AMDo6JKcHAVCafngdQ1jRNlML
0CGT92GgQ6PGD7Ea5oy1zqu7gub1vYpFrI_3s2tVD_2nRIAgQuSVW5ckSxcX4Xh6Qukiu1woKkM5H1
6_Pm5iY4jexXKkQDWlfsCsANtFCopYfOuX1lkm5DqqTwDJL3sixh5eQKr5gtKAd8jzgcV5rfalNcKt
gozW2cGyVO7Co9jjWqchs6ZyOo7Z8mZgxyBkYOI-r73Nv6vplrHgvWe3azGEcgYSl_NN4E0GWu2Qnf
4i9kjvwGwRN_YwMYthArkxYgE8FBt2xrPOq3GV09w4H3mGXHOWjB_H_C7uUPTztbGNDqX4w7R7NMd3
dY5Cu1WYUB_W1AV_BhhAoUUoAoE
Her er det returnerede adgangstoken:
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Content-Type: application/json;charset=UTF-8
{
"access_token": "AYDWAgEzUqeVsVtcA4ndY25qGFVyaId75im2glOV5Eoog2XajaEjdQlndD7RveqpL7G",
"token_type": "Bearer"
}
Derefter kan du bruge adgangstokenet til at foretage tjenesteanmodninger:
GET /resource HTTP/1.1
Host: api.devicebackend.com
Authorization: Bearer AYDWAgEzUqeVsVtcA4ndY25qGFVyaId75im2glOV5Eoog2XajaEjdQlndD7RveqpL7G
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store
Content-Type: application/json;charset=UTF-8
{"some": "data"}
Valider aktivtokener
Aktivtokener er standard-JWT'er, hvilket betyder, at valideringen følger standardtrinene i RFC 7519- specifikationen, afsnit 7.2. Det anbefales, at du bruger et open source-bibliotek til validering af JWT'er snarere end at skrive din egen signaturvalideringskode.
- Opdel aktivtokenet i tre dele adskilt af tegnet punktum (.).
- Base64url afkoder den første del af sidehovedet, idet den følger den begrænsning, at ingen linjeskift, mellemrum eller andre tegn er blevet brugt.
- Bekræft, at den resulterende octet-sekvens er et UTF-8-kodet JSON-objekt.
- Udtræk kid-kravet (Key ID) fra sidehovedet.
- Hvis det er nødvendigt, kan du hente denne nøgle fra nøgleslutpunktet. Nøglen bliver din Experience Cloud-lokalitets URL (eller Mit domæne-URL) med
/id/keystilføjet.
Bemærk Nøglenavnet er entydigt for udstederen og er ikke globalt entydigt. - Bekræft JWS i henhold til RFC 7515-specifikationen.
- Kør RSA SHA256-signaturvalidering over
header.payload.-afsnittet. - Gør resultatet Base64url-kodet.
- Sammenlign det med den præsenterede signatur.
- Kør RSA SHA256-signaturvalidering over
Populære open source-biblioteker til validering af JWT'er inkluderer:
- Java: jose4j – Du kan bruge denne erklæring til din Maven POM-fil:
<dependency><groupId>org.bitbucket.b_c</groupId><artifactId>jose4j</artifactId><version>0.4.4</ve rsion></dependency> - .NET:
Install-Package System.IdentityModel.Tokens.Jwt - Node:
npm install jsonwebtoken - Python:
pip install pyjwt - PHP:
composer require firebase/php-jwt - Ruby:
gem install jwt
Her er der et eksempel i Java på, hvordan du bekræfter et aktivtoken ved brug af jose4j:
package your.company
import org.jose4j.jwk.Ht psJwks;
import org.jose4j.jwt.JwtClaims;
import org.jose4j.jwt.consumer.InvalidJwtException;
import org.jose4j.jwt.consumer.JwtConsumer;
import org.jose4j.jwt.consumer.JwtConsumerBuilder;
import org.jose4j.keys.resolvers.HttpsJwksVerificationKeyResolver;
import org.json.JSONObject;
import javax.servlet.ServletException;
import javax.servlet.ht p.HttpServlet;
import javax.servlet.ht p.HttpServletRequest;
import javax.servlet.ht p.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;
public class IngestAPIExample extends HttpServlet {
private static final String ISSUER = "https://customersite.my.site.com";
private static final String KEY_ENDPOINT = ISSUER + "/id/keys";
private static final String AUDIENCE = "https://your.devicebackend.com";
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
boolean isValidAssetToken = false;
// Get the asset token from the HTTP Authorization header, removing the "Bearer "
String authHeader = request.getHeader("Authorization");
String assetToken = authHeader.substring(7);
// The HttpsJwksVerificationKeyResolver uses JWKs obtained from the HttpsJwks and
// selects the most appropriate one to use for verification based on the Key ID and other factors
// provided in the header of the JWS/JWT.
HttpsJwks httpsJkws = new HttpsJwks(KEY_ENDPOINT);
HttpsJwksVerificationKeyResolver httpsJwksKeyResolver = new
HttpsJwksVerificationKeyResolver(httpsJkws);
// The JwtConsumer establishes the rules for Validation of our asset token.
JwtConsumer jwtConsumer = new JwtConsumerBuilder()
.setVerificationKeyResolver(httpsJwksKeyResolver)
.setRequireExpirationTime() // The JWT must have an expiration time.
.setAllowedClockSkewInSeconds(30) // Allow some leeway in validating time-based claims to account for clock skew.
.setExpectedIssuer(ISSUER) // Entity that the asset token must be issued by.
.setExpectedAudience(AUDIENCE) // Entity that the asset token is intended for.
.build(); // Create the JwtConsumer instance.
try {
// Validate the JWT and process it to the Claims.
JwtClaims jwtClaims = jwtConsumer.processToClaims(assetToken);
isValidAssetToken = true;
} catch (InvalidJwtException e) {
// InvalidJwtException thrown if the asset token failed processing or validation.
System.out.println("Invalid Asset Token: " + e);
}
// If your asset token is valid, do something here with your data. For purposes of our example, we’re done.
PrintWriter out = response.getWriter();
JSONObject r = new JSONObject();
r.put("valid", isValidAssetToken);
out.close();
}
}

