Security is important for us at Trygg Hansa, therefore we have strict requirements on the SSL protocol and cipher used, we also require two different security keys when you send an API request to our systems.
Client Credentials Flow
We use the Client Credentials Flow from OAuth 2.0 to handle the backend environment authorization, this means that you will need to send a request to start with to our authentication server to get a valid token which can be reused for subsecent requests within one hour.
For more information about OAuth 2.0 please see https://www.rfc-editor.org/rfc/rfc6749#section-1.3.4
We will share the correct url, credentials and scope with you in the onboarding process.
URL https://login.microsoftonline.com/our_tentant_id/oauth2/v2.0/token
Multipart formclient_id : 31e49a09-a673-42ab-9c8e-937fc4c36a0cclient_secret : fd234~4324_FADSFew2...scope : https://exampleapplication-tryg.msappproxy.net/.defaultgrant_type : client_credentials
Once a bearer token has been aquired simply send it along in the requests to the APIs in the Authorization header.
Authorization : Bearer + eyJ0eXAiOiJKV1QiLCJh...API Subscription Key
The second part is the required API Subscription Key to ensure that you target the correct API in the API Portal.
When you login to the API Portal with your credentials, you can find the API specific key under your profile.
Similar to the bearer token in the previous section, simply send it along in the requests in a custom Ocp-Apim-Subscription-Key header.
Ocp-Apim-Subscription-Key : fdaa9add342123...TLS and Cipher suites
We only allow requests are that use TLS v1.2 as a minimum version, together with the following ciphers:
TLS_AES_128_GCM_SHA256TLS_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
What this means in essence is that if you use a relatively new system, everything will work out of the box regarding the TLS and cipher used.