Diff for /documentation/concepts/api_concepts/authentication/index.md
On this page, you can preview the modified document with the changes.
Note that the links within this diff are most likely broken because they are
relative to the original document or
point to another document that is not part of the changeset.
Authentication
We have a two-fold authentication framework to ensure that the caller of the API is known and that calls have not been tampered with en route.
How authentication works
OAuth 2.0
The Investment API uses opaque access tokens obtained using the OAuth 2.0 Client Credentials flow.
During the onboarding process, each client receives a client ID and a client secret that can be used to request access tokens via our OAuth2 endpoints.
Authentication scopes
The Upvest Investment API supports granular authentication scopes, thus improving security. You can restrict the permissions and data that is requested during authentication by specifying the scopes.
The following table lists available scopes:
Request a users:read
access token to read user data but not be able to change user data. Then request a users:admin
access token to be able to onboard new users.
More on available permissions see here.
Once the access token is returned, the token can be used in all requests for the specific required scopes using the standard authorization header as shown below:
Example header
Authorization: Bearer <access_token>
The use of client_credentials
alone allows us to identify you and authorise your request. However, it does not protect against a man-in-the-middle attack, where the request can be maliciously modified. To mitigate this risk, there is an additional layer of public key infrastructure in the form of HTTP signatures.
HTTP signatures
OAuth 2.0 is only used to authenticate your client backend calling the Upvest API (i.e. to know who is the client calling the Upvest API). In addition, we also want to make sure that the call is actually coming from your backend and has not been tampered with along the way. For this we use HTTP message signatures
HTTP message signatures should be considered transparent and any request sent to the Investment API must be signed with the private key corresponding to the OAuth 2.0 client_id
. If this is not the case, the request will be rejected.
Once HTTP signatures are in place, normal OAuth 2.0 flows can be used. To do this, get a scoped access token with client_id
and client_secret
and use the access token to call the Investment API.
Detailed instructions on how to calculate the signature can be found here.