This section explains the login & authentication flow of web-based application.
Overall, the login process consists of 2 steps:
Authentication - Single SignOn
- Acquiring an Access Token
Step 2 is identical to the process used by a native application, but the first step is a bit different.
But before you can get started, the application must be registered, which would provide the following pieces of information:
|Name||Description||Value used in the examples below|
A URL uniquely representing your app - this was provided to you when you registered for the developer license.
|AuthenticationUrl||The URL of the Saxo Bank authentication & authorization server - this was provided to you when you registered|
|AppKey||The Application key identifying your application to Saxo Bank - this was provided to you when you registered||-|
|AppSecret||The Application "secret" identifying your application to Saxo Bank - this was provided to you when you registered||-|
|OpenApiBaseUrl||Base URL for calling OpenAPI REST endpoints.|
Never expose your AppKey and AppSecret to the users of your app - read our recommendations on security regarding AppKey and AppSecret here.
Authentication - Single SignOn
The first step in the authentication process, is sending a SAML Authentication request to SSO. This is a POST request, containing a Base64 encoded SAML request as shown below:
In above code block, these fields are of important relevance:
|Field||Description||line no. in example|
|ID||A unique ID - in the example above it is a guid preceded by a "_"||1|
|IssueInstant||The Request time (UTC, ISO 8601 formatted)||3|
The URL of the authentication endpoint (the same that the request is actually sent to).
Destination = AuthenticationUrl + "/AuthnRequest".
This is Application URL aka the URL of the page that should receive the authentication response. This must be a page under the service provider URL that your application has been registered with in Saxo Bank.
|saml:Issuer (tag contents)||The URL of the page issuing the request.||6|
The SAML request, must be POSTed as
SAMLRequest to the authentication endpoint which is AuthenticationUrl + "/AuthnRequest" (e.g.
https://sim.logonvalidation.net/AuthnRequest for the SIM environment). For more info on various environments, visit - Link.
Below is the code construct from example to generate the request SAML:
If the user is not already logged in to SSO, it will redirect the user agent to the login dialog (which is why the request should be sent from the browser itself, and not server-to-server).
After the authentication is finished (whether it required the login dialog or not), SSO posts the result back to the page specified in the "AssertionConsumerServiceURL".
The POST request contains a single field: "
SAMLResponse", which contains a Base64 encoded SAML response like the one showed here (certificate and signature tags truncated for the sake of brevity):
This response contains info for verifying the validity of the response (and sender) and that of the intended "audience" (this should be your site) – but for the sake of requesting the token, it is the AuthorizationCode attribute value that is important because this is what we use in next step: Acquiring an Access Token.
The AuthorizationCode value node can be found using the XPath expression: "
Get Access Token
Having the authorization code in hand, we can now exchange this for an Access Token by sending POST request to authorization url which is AuthenticationUrl + "/token" (e.g. for simulation its
https://sim.logonvalidation.net/token i.e. AuthenticationUrl + "/token" ).
POST request must contain the following:
- The endpoint to this is " " (for simulation)
- The POST request takes the parameters
code=<the authorization code from SSO>
- The authorization header contains the application key and app secret that you receive from Saxo Bank upon registering you application. The "<appKey>:<appSecret>" pair is Base64 encoded and prefixed by "
The response from the token endpoint is a JSON object containing Access Token as well as a Refresh Token which is used for acquiring more tokens when the current one expires:
token_type) values are used for calling OpenApi, and should be placed in some kind of persistent storage, to avoid unnecessary re-authentication.
The refresh_token value is used for getting a replacement token when the existing one is expiring. "
expires_in" and "
refresh_token_expires_in" are integer values that contain the expiry intervals (in seconds) for token and refresh token respectably.
Using Access Token
When the client application needs to invoke an OpenApi service, the token & token type are combined and put into the Authorization headers like this:
Refresh Access Token
Since the Access Token has a limited lifespan, it needs to be refreshed at regular intervals. For the same, token response contains a refresh token that has a longer expiry than the token itself and that can be exchanged for a new token.
The request for a new token is made against the same endpoint that the original token request was made, the only difference to the original request is the payload of the request as can be seen in below snapshot:
In the payload of the refresh request, the
grant_type is set to
refresh_token and the actual refresh token is provided in a parameter named
refresh_token, but the rest of the request is identical - it also needs the appKey and -secret to identify the application, and the returned JSON structure is identical - so you get a new token and a new refresh token.
Authentication Sequence Diagram
Sequence diagram of login flow is shown below: