“Can you explain what are RESTful web services? How do they compare to SOAP web services?”
“Can you tell us about your understanding of the OAuth 2.0 standard?”
These questions threw me off guard when I was interviewing at GovTech 2 years ago. And no, I’m neither an old fogey nor a time traveller from medieval times. I exaggerate, but I had expected questions from the 1950s since I was interviewing at a government agency. I could have better spent my nights rather than taking history lessons on mainframes, Cobol, and the likes of them.
Long story short, I got through the interview successfully and started on an exciting journey with MyInfo.
Slippery SOAP, Peaceful REST
“We need to define RESTful endpoints that match our SOAP-equivalent ones. Then we migrate our users over.” Without a surprise, my first task was to define RESTful APIs to replace their SOAP counterparts.
MyInfo, along with many government agencies’ services, were early adopters of the Service Oriented Architecture (SOA), which also happened to be the best technology available then.
However, time and tide wait for no man. Even though the landscape became dominated by SOAP as the established protocol, with the rise of the REST architectural style, many organisations have started to embrace it, as it’s the arguably easier to code for, easier to consume and more network-friendly new kid on the block.
Riding on the opportunity to release MyInfo to the private sector, our RESTful APIs made their first debut on March 2017.
It’s “MY” Profile!
The roll out was successful, but not without bumps. Enquiries started to pour in through emails and calls, flooding our helpdesk support.
I comforted myself thinking, “it’s a good problem to have”, and at the same time mentally prepared myself for the worst.
Thankfully, the volley of enquiries gave us insight into concerns which could be helped with good communication. Among the thorns, a particular concern stood out: the Singapore Government is sharing “MY” profile data.
Although everyone enjoys the efficiency of doing things online, privacy in the digital space is a big thing. While the Government may have information specific to you from previous transactions, it doesn’t mean that your data will be shared with any Tom, Dick, or Harry at any time.
As it turns out, the Government cannot simply share YOUR data. We strongly abide by this rule: “Being able to do something doesn’t automatically give us the right to do it”.
The decision to use MyInfo is entirely in the hands of the user:
- You can resist the urge to click on the big red “MyInfo” button promising to shorten your transaction time down to 5 mins
- If you do use MyInfo to pre-fill any forms, you can still decline giving consent (yes, you guessed it, using the OAuth standard) to MyInfo releasing your data to the legitimate business entity that is registered with ACRA (not just any Tom, Dick, or Harry)
- You can start the relatively labourious process of filling up digital forms provided by the relevant government services, photocopying your NRIC/passport, CPF, and IRAS statements, among other required documents, and choose to make your way down to the respective service centres to complete your transaction
It’s up to you.
O-What? How does it work?
OAuth 2.0 (pronounced “oh-auth”) is an authorisation framework that many modern applications tap on to request for user consent in order to access user-owned resources.
In a nutshell, the OAuth flow starts with an application requiring access to some resources owned by the user, followed by user redirection to an OAuth server for consent. The OAuth server presents a consent page which states the application and the resources requested for the user’s perusal. Upon given consent, an authorisation code is generated and sent back to the requesting application via a redirection. With the code, the application can then exchange it for an access token which represents the permission given to access the user-owned resources.
I tl;dr’d OAuth in one paragraph! Achievement unlocked. Let’s get back to MyInfo.
MyInfo defines user profile attributes as user-owned resources and adopts an all-or-nothing approach in releasing data in order to achieve a straight-through process for most digital services.
On one hand, some may argue that a few of the requested attributes are not mandatory for the transaction, so, why aren’t we letting the user have a say on which attributes to release? If you’re familiar with how this works, you’ll guess correctly that it’s not as straightforward as it sounds, and it introduces complexity for all involved parties. C’mon, give us a break, we’re barely 2 years old (and we’re still trying to improve)!
A chain is as strong as its weakest link
“Bear in mind, MyInfo deals with personal data, yours included. So, is the design safe?” A common question my boss and chief architect have repeatedly asked.
Relying on a series of redirections via browsers, vanilla OAuth flow is vulnerable to man-in-the-middle (MITM) attacks where malicious users can intercept such traffic over public networks, and gain enough information to masquerade as the requesting application to call for the access token. Once the access token is acquired, the malicious user will be able to access the so-called protected user resources.
This was a security gap we needed to plug before we rolled out MyInfo. We needed a stronger authentication mechanism to prove the identity of the requesting application, and we landed on a PKI-based solution. The crux of the solution laid in:
- An out of band on-boarding process, where MyInfo receives the public certificate of the application, signed by a trusted Certificate Authority
- The application safekeeping its own private key
- The application generating digital signatures using their private key and MyInfo verifying them using the application’s public certificate
Find out the details of our solution by visiting our Developer & Partner Portal.
And so, we’re done! Or are we? Someone once told me that security is a never-ending pursuit and the key to perfect security for any system is to unplug it from all networks. Hmm… I guess there is no option except to keep on chasing.
Eh, why you reject my certificate?
One of the less exciting parts of my job — to repeat that which is already documented and published on the internet.
No, we don’t accept self-signed certificates. Only certificates signed by trusted Certificate Authorities published on our Developer & Partner Portal will be accepted.
Since we’re dealing with personal data, we need to make sure that the data is requested by, and sent to legitimate partners. We require our partners to obtain certificates, which digitally binds a public key to a user, from trusted Certificate Authorities who provide the assurance that requesters are verified before certificates are issued.
My digital signature not correct meh?
Another less than exciting part of my job — troubleshooting (which typically involves repeating published documentation). Here are some tips to help in your initial analysis for what could have gone wrong:
Self Help #1: Check the error message in the response body, which will give you clues to what might be wrong.
Self Help #2: Check the signature produced using your public certificate.
Self Help #3: Check that the HTTP request parameters sent correspond to those used to produce the signature.
If all else fails, send an email to email@example.com and one of our friendly team members will get back to you as soon as possible.
Want to be a partner? Check out our Developer & Partner Portal or talk to us at https://go.gov.sg/engage-NDI.