wiki-spaces-s1-pages-2698084353-3-dot-2-dot-4-plus-authentifizierung-plus-maschine-plus-zu-plus-maschine-plus-m2m.md
By Mayer, Wolfram
2 min
Add a reaction
In diesem Szenario wird OAuth 2 Client Credentials Grant verwendet. (definiert in RFC 6749, Abschnitt 4.4), wobei eine Anwendung mithilfe ihrer Client-Anmeldeinformationen (einer Client-ID und eines Client-Secret) direkt ein Zugriffstoken vom Autorisierungsserver anfordern kann. Anstatt einen Ressourceneigentümer (Ressource Owner) zu identifizieren, stellt dieses Token die Anwendung selbst dar.
Beantragen Sie Client ID / Client Secret mit folgendem Formular per E-Mail an [email protected]: 2.3 Client-ID für eigene native App erzeugen
Um Sage ID nach Tokens für eine Ihrer autorisierten Anwendungen zu fragen, führen Sie einen POST-Vorgang für den Endpunkt https://id.sage.com/oauth/token mit einer Nutzlast im folgenden Format durch:
`Accept: application/json Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&client_id=IHR_CLIENT_ID&client_secret=IHR_CLIENT_SECRET&audience=IHR_API_IDENTIFIER`
Bitte beachten Sie, dass im obigen Beispiel jeder Parameter gemäß RFC1866 Abschnitt 8.2.1 URL-codiert sein muss, sodass Leerzeichen als + (Plus)-Zeichen codiert werden müssen.
Sie können auch einen JSON-formatierten Payload verwenden, z. B.
Accept: application/json Content-Type: application/json { "grant_type":"client_credentials", "client_id": "IHR_CLIENT_ID", "client_secret": "IHR_CLIENT_SECRET", "audience": "IHR_API_IDENTIFIER" }
Die Antwort enthält ein signiertes JSON-Web-Token, den Typ des Tokens (Bearer) und die Zeitspanne, in der es in Unix-Zeit abläuft.
{ "iss": "https://id-shadow.sage.com/", "sub": "IHR_MACHINE_TO_MACHINE_APPLICATION_CLIENT_ID@clients", "aud": "IHR_API_IDENTIFIER", "exp": 1489715431, // unix timestamp der token's Ablaufdatum (expiration date), "iat": 1489679431, // unix timestamp des token's Erzeugungsdatum (creation date), "scope": "" }
Ihr Dienst muss das Zugriffstoken zwischenspeichern z.B. in einem Cache. Über das Feld „expires_in“ kann festgelegt werden, wie lange der Token zwischengespeichert werden soll.
Für den OAuth-/Token-Endpunkt gelten Ratenbegrenzungen. Daher ist Caching eine Voraussetzung und jeder Dienst, der seine Zugriffstoken nicht zwischenspeichert, wird deaktiviert.
Client Secrets müssen auf sichere Weise geschützt werden. Im Folgenden finden Sie Vorschläge, die als schlechte und bewährte Vorgehensweisen zum sicheren Schutz eines Client Secrets angesehen werden können.
Eine schlechte Praxis besteht darin, ein Client Secret im Klartext im Code zu haben, es im Klartext an Repositories zu übergeben oder das Geheimnis in Konfigurationsdateien (appsettings.json, app.config, web.config) zu haben. Unkontrollierter Zugriff auf Secrets in z.B. Der Passwort-Manager über das Master-Passwort wird als schlechte Praxis angesehen. Senden Sie Secrets über ungesicherte Kanäle, z. B. Standard-E-Mails ist ebenfalls schlechte Praxis.
Eine gute Vorgehensweise besteht darin, Client Secrets verschlüsselt zu speichern. Speichern Sie Client Secrets nach Möglichkeit im Azure Key Vault, im AWS Secrets Manager oder im Google Cloud Key Management Service. Verwenden Sie Dienste wie Azure Active Directory oder Access Management (IAM), um den Zugriff auf diese Schlüsseltresordienste (Key Vaults) zu steuern. Ein Secret sollte nur über verschlüsselte Kanäle, z. B. Gesicherter E-Mail-Anbieter für eine sehr begrenzte Anzahl von Empfängern.
Erhalten einen Access Token über Client Credential Grat Flow (M2M), um einen Aufruf der Sage 100 API umsetzen zu können. Der Authorization Code vom vorhergehenden Schritt wird verwendet, der an /oauth/token per POST gesendet werden kann.
var client = new RestSharp.RestClient(); var request = new RestRequest(new Uri("https://id.sage.com/oauth/token"), Method.Post); request.RequestFormat = DataFormat.Json; request.AddJsonBody(new { grant_type = "client_credentialse", client_id = "IHR_CLIENT_ID", client_secret = "IHR_CLIENT_SECRET", audience = "IHR_API_IDENTIFIER" }); RestResponse response = await client.ExecuteAsync(request);
The Antwort enthält iss (issuer), sub (subject), aud (audience), exp (expiration), iat und scope.
{ "iss": "https://id-shadow.sage.com/", "sub": "IHR_MACHINE_TO_MACHINE_APPLICATION_CLIENT_ID@clients", "aud": "IHR_API_IDENTIFIER", "exp": 1489715431, // unix timestamp der token's Ablaufdatum (expiration date), "iat": 1489679431, // unix timestamp des token's Erzeugungsdatum (creation date), "scope": "" }
Als IHR_API_IDENTIFIER sollte s100bp/sage100m2m verwendet werden im Sage 100 Kontext.
Sobald das Zugriffstoken erhalten wurde, kann es für Aufrufe an die API verwendet werden, indem es als Bearer-Token im Authorization-Header der HTTP-Anfrage übergeben wird:
var client = new RestClient("https://connectivity.sage.de/ws/<IHRE_ENTITLEMENTID>/sdata/<IHRE_SDATA_URL>"); var request = new RestRequest(Method.GET); request.AddHeader("authorization", "Bearer ACCESS_TOKEN"); request.AddHeader("content-type", "application/json"); request.AddHeader("X-Sage-ConnectivityVersion", "1.3"); IRestResponse response = client.Execute(request);
Collapse action bar
View all comments
Open Details Panel
Create page
Open Rovo Chat
Add a comment
Add a reaction