If you are looking for our old authentication flows, please find them here: SAML Based Authentication Flows.
All Saxo Bank's OpenAPI endpoints require that the calling application includes an OpenAPI access token. The method through which the application gets this token follows one of the OAuth 2.0 flows that we support.
The following provides a high-level overview of what it takes to autenticate with Saxo's OpenAPI, as well as an overview of the various ways to obtain an access token.
If you just want to get started quickly, you can use the "OpenAPI token" feature on the developer portal to get an access token for your account on our simulation system. Each token is valid for 24 hours and saves you from having to implement a full authentication flow.
Get OpenAPI Application Key
To get started you must have an OpenAPI Application Key and Application Secret. You can get these values by applying for a simulation application. We can also recommend reviewing our FAQ "Getting Started" to answer the most commonly asked questions.
Recommendations on AppKey and AppSecret security
You should never expose your AppKey and AppSecret to your users, for instance by embedding them into a JavaScript-Application.
If any 3rd party can access your AppKey and AppSecret, they can access OpenAPI as if they were your application, and potentially cause havoc that will be attributed to your application. If you are implementing only a JavaScript Application, You should still keep the AppKey and AppSecret on your server and only expose the AccessToken to JavaScript Application, for instance by a web service.
Get Access Token from Authentication Server
Depending on your application type you must go through one of the login scenarios described below. This will give you an access token and possibly a refresh token.
Access Token Contents and Interface Classification
The access token contains a number of properties, which affect how an OpenAPI endpoint responds to a request.
The table below is only for informational purposes. It is not the intention that a client application should try to decrypt and/or interpret the contents of an access token, and Saxo Bank may change to contents and format of the token at any time.
| Property | Meaning/Determines |
|---|---|
| "UserId" | Identifies the user on behalf of which this call is being made. This obviously controls which accounts can be accessed. |
| "AppId" | Identifies the application. (Your application in this case). |
| "Claims" | OpenAPI resources are grouped by "access level" (Public, Restricted, Community, Personal, Confidential). For each of these access levels the claims specify if the calling application is allows to:
|
| "LifeTime" | When is this token no longer valid. |
The contents of the access token depends on how your application has been configured, when it is set up in Saxo Bank's security system. You will receive information about the claims allocated to your application along with your application key and secret.
When a request is made to OpenAPI endpoint, the claims in the token are matched with those required by an individual endpoint. These requirements are documented in the reference documentation in the "Resource Info" box.
For example, in order to place a trade, your access token must have access "Write" to OpenAPI endpoints marked "Personal".
Pass Access Token to an OpenAPI Endpoint
Your application must include the access token in every request to an OpenAPI endpoint. The access token may be used multiple times as long as it is still valid.
Refresh Access Token, if Necessary
Access tokens have limited lifetimes. If your application needs access to an API beyond the lifetime of a single access token, it can either:
- Go through the complete login flow again
- Use a refresh token to request a new access token. Using a refresh token is much simpler as it requires no user interaction. Under certain circumstances it even allows an application to get a new access token after the user has logged off. This is very useful for applications which monitors a portfolio or which conduct automatic trading.
Make sure you store refresh tokens in a secure long-term storage. You may continue to use them as long as they are valid. Every time you use a refresh token to get a new access token, you also get a new refresh token, this refresh token replaces and invalidates the previous refresh token.
Single Sign-On and Federated Single Sign-on
The authentication protocol actually supports both Single Sign-On and Federated Single Sign-on. It also has full support for Saxo Bank's White Label installations. These are however advanced topics which require extra development steps, exchange of certificates etc.. These will be discussed directly with the individual development team when the need has been identified.
Selecting the Right Authentication Flow
Which authentication flow should be used is primarily dependent on the type of application. Below is a short introduction to the most common application types and which authentication flow we recommend.
Server-side Web Application
Traditional web applications that generate the pages server-side should use the OAuth: Authorization Code Grant flow.
Native Application
Native applications, where the source code is compiled, should use a variation of the Authorization Code Grant that includes an additional measure, Proof Key for Code Exchange (PKCE), to prevent the authorization code from being intercepted. This flow is described in the OAuth: Authorization Code Grant (PKCE) article.
Single-Page Applications (SPAs)
Single-page applications cannot hold any secrets, and are therefore unable to receive and use an Application Secret as required for most OAuth flows. Therefore it needs to authenticate using the OAuth: Implicit Flow, where authentication is only done using the Application Key, but as a result the app will not receive a refresh token.
Certificate Based Authentication
This type of authentication is only available to select partners upon request.
Certificate Based Authentication is designed for server-to-server authentication where it is not feasible to require human authentication. Our implementation is based on Json Web Tokens and is described in the OAuth: Certificate Based Authentication article.