Veeqo now supports OAuth

Information
1

Veeqo now supports OAuth.

The update has been deployed and is now in a open beta. We’ve completed our initial testing and it all looks to be working well. We still need to update the documentation and there are few manual steps that need to be automated. However it is a much faster and more secure way of authentication for your apps in Veeqo - especially if your application is intended for public use by other Veeqo users.

We need you to give us your feedback on how it works and what we need to improve. Instructions follow.

OAuth Setup

0. Application Set Up

(This is the manual step that will eventually be automated)

Create a redirect_uri and let us know your application name. We will then send you your client_id and client_secret.

1. Authorizing the user

Assuming our application is set up like so:

2. Get authorization code

It is returned in the code param of the redirect uri (e.g. http://example.com/test_oauth_callback?code=acc2658ced4f9eea257c9da72acea1c97f9e1b1db2118b565355532af13591d7) - this code lasts only 10 minutes

3. Make a request for the permanent token

Make a request to https://api.veeqo.com/oauth/token using client id, client secret, temporary code, e.g:

Request URL: /oauth/token

Method: POST

Params:
grant_type: authorization_code

redirect_uri: http://example.com/test_oauth_callback

client id: 4f8a5d37071f0955e3c8a3dcbf3ff0b53c0699d2085cc6b01707fb3eb9912652

client secret: dd04814c033fdbc9a01a9b68100d359edaa41d8ad702a03ae221dd456da1d59c

code: acc2658ced4f9eea257c9da72acea1c97f9e1b1db2118b565355532af13591d7

Should return a response like so:

{
    "access_token": "82d7b651f3634a5243c4155f8832f09b30de0c115280d0c2ef62512e6bc5312e",
    "token_type": "bearer",
    "created_at": 1510741588
}

access_token is the token to use in further requests - should be saved permanently!

4. Save the access_token value

This should be saved from the last request

5. Make a request

Make a request like normal with our bearer token, e.g.

Request URL: /current_user

Method: GET

Headers:
Authorization: Bearer 82d7b651f3634a5243c4155f8832f09b30de0c115280d0c2ef62512e6bc5312e

3

Just to say, if you’re a bit of an OAuth noob like myself, you need to post the temporary authorization code in with the parameters too.

code: acc2658ced4f9eea257c9da72acea1c97f9e1b1db2118b565355532af13591d7
(from the example above)

1 Like
4

Hi,

This is article was from 2018, I suspect no UI to obtain clientId & clientSecret?

I have a test app, with a sandbox account…Who do I contact to get creds?

Stay Safe,

5

Hi @sam123, Reaching out again to understand the next steps. Could I send you our test callback uri and and application name to receive the clientId and clientSecret?

Regards,

6

I now have creds! Thank you Laura!

I just wanted to touch into an area that’s not been covered here or in the documentation. A link to OAuth may not help others if it’s buried in nested pages.

The State object/string This is absolutely essential to protect against CSRF in the redirect flow. All this means from a developers perspective is to ensure the request came from veeqo, by passing an object or a classic guid string when sending an authorize request.

Store the state that you created to cross reference later.

C# Example:

var state = Guid.NewGuid().ToString();
string url = $"{OAuthAuthorizeUrl}?response_type={ResponseType}&client_id={ClientId}&redirect_uri={CallbackUri}&state={state}";

When the user approves access to veeqo, the callback Uri (redirect Uri) will contain the state string in the query string.

Obtain the state sent from veeqo and cross reference with the state previously stored… They’ll match! and this ensures the request came from veeqo.

state
state797×690 39 KB

Snippet from OAuth best practices:

Clients MUST prevent Cross-Site Request Forgery (CSRF). In this context, CSRF refers to requests to the redirection endpoint that do not originate at the authorization server, but a malicious third party (see Section 4.4.1.8. of [RFC6819] for details). Clients that have ensured that the authorization server supports PKCE [RFC7636] MAY rely the CSRF protection provided by PKCE. In OpenID Connect flows, the “nonce” parameter provides CSRF protection. Otherwise, one-time use CSRF tokens carried in the “state” parameter that are securely bound to the user agent MUST be used for CSRF protection (see Section 4.7.1).

Further steps can be found here:

Hopefully the above helps someone that may miss some of the “MUST” steps in security.

Regards,

1 Like
8

Thanks for sharing :grin: