Wednesday, September 20, 2017


One Identity recently launched Starling Two Factor Authentication, a SaaS-based solution.

It solves the password problem without the capital costs or increased infrastructure management that you might incur with traditional on-premises solutions. With an easy to use dashboard for administrators and flexible authentication options for end users, Starling Two-Factor Authentication enables organizations to quickly and easily verify a user’s identity.

Starling Two Factor Authentication is actually based on Authy.

The nice thing about Authy is that it provides REST APIs which is useful for application integration which requires 2-Factor authentication. e.g OneTouch APIPhone Verification API

Cool stuff!


Monday, September 18, 2017

More APIs integration with IRAS (Singapore Taxman)

I blogged about More and more APIs exposed by Ministries. Yesterday, I read about Taxman calls on Grab, Uber drivers from Straits Times.

Dodging the taxman will become more difficult in the gig economy, as going cashless allows for better electronic tracking of payments. And the taxman has his sights next on Uber and Grab drivers.

An Iras spokesman said: "To simplify tax filing and ease compliance for our taxpayers, Iras continually seeks ways to explore initiatives with third parties and platform providers to automate the transmission of income information directly into our tax systems."

What's the end state?

Definitely a gateway (Grab/Uber) with gateway (IRAS) integration with Grab/Uber automatically submitting drivers' earnings directly to IRAS - same as the one we are implementing right now for an Insurance agency in Singapore.


Tuesday, September 5, 2017

API Design - Initiate Optimize

In my previous blog, I talked about a customer of mine who worried about too many calls hitting her API Gateway.

As we have seen quite a number of API deployment gone live, these are typical worries. One has to treat this type of project as a Full Lifecycle API Management journey. API deployment cannot be treated as a one-off project.

The worry that the customer had is where we will usually Initiate Optimize as illustrated in the diagram above.

  • Optimize the way the application requests for a OAuth2 access token by reusing an established access token
  • Optimize by increasing the OAuth2 access token timeout 

Are we able to foresee every possible performance issue that will surface after go-Live? Very hard.

Why? APIs are exposed to consumers in the public. There are no fixed usage pattern. We can usually optimize based on past experience, but usually tweaking is required after go-Live for each deployment.


Monday, September 4, 2017

Client Credential Grant Type and Refresh Token

I was in a discussion with a customer today and we talked about how to reduce the number of calls to Kong API Gateway.

This particular API Gateway is only for internal applications communication, thus Client Credential Grant is configured on each endpoint.

The main concern was that prior to each endpoint call, the internal applications have to make a call to request for a OAuth2 access token. This will be 2 calls to the Kong API Gateway per endpoint.

But, hey, if this is a setup of internal applications communication, we can increase the access token timeout. And it is programming best practice to reuse established access token, rather than to get a new access token prior to each endpoint call.

There's a choice.

The APIs are not exposed to the public. If the application teams within the same company cannot cooperate with one another, there's nothing we can do about it.

The customer continued to probe further: "Can't we ask the application team to use the OAuth2 refresh token to exchange for a new OAuth2 access token?"

But... this is Client Credential Grant type. There's no refresh token generated.

Refresh tokens are only provided when retrieving a token using the Authorization Code or User Credentials grant types.


Friday, September 1, 2017

Stock Trading RESTfully

IG Group is a UK-based company providing trading in financial derivatives such as contracts for difference and financial spread betting and, as of 2014, stockbroking to retail traders.

I just came across their trading platform and discovered that they have "API-exposed" their trading system via IG Labs.

This is cool for experienced traders who want to apply their own trading algorithm before they make a trade (either open or close) for automated trading. 

I am seeing this as a trend moving forward...

I searched the local trading securities in Singapore. I think most have just poured their champagne by delivering their Mobile trading platform. 

None has exposed their trading platform as APIs yet. But surely the day will come... just a matter of time!


Thursday, August 31, 2017

API Development - Not Engaging Early Enough

I was reading a blog from Nordic APIs - 5 Frequent Developer Community Mistakes (And How to Fix Them).

I could relate quite closely to one of the mistakes - Not Engaging Early Enough.

Many of us make this mistake frequently. We thought we have a great API to launch, but we actually do not really know what the market is looking for!

A new development process is suggested:

  • Idea : Generate initial tech design documents. 
  • Think: Add some context to those documents, make them more digestible, explain motivation, come up with NDAs. 
  • Explore: Send to a small subset of developers for feedback. 


  • Build
  • Launch
  • Tweak

Great reminder!


Tuesday, August 29, 2017

More and more APIs exposed by Ministries

The trend is pretty clear these days - ministries in Singapore are encouraged to expose more and more APIs for external entities to consume, in particular organizations/companies.

This will save huge amount of human hours if manual tasks like Form Submissions can be automated. Yes, we have a labour crunch here in Singapore. We do not have enough local people in our workforce. Thus automation is key going forward!

My team is currently designing APIs for one of the financial institutions in Singapore. This week, we have a new request to integrate with Inland Revenue Authority of Singapore (IRAS) for Commission Income Information Submission.

The current process of submission is very manual.

It requires a person to download a program (Offline Validation Program - OVP) from IRAS to validate a XML/Excel file. Once validated, one has to log in via SingPass (Singapore Personal Access) and then manually upload the XML/Excel file to IRAS portal.

The new API service allows applications to directly submit Commission Income Information to IRAS , thus eliminating the need to download and validate using OVP and login to IRAS portal for submission.