This is a slight departure from my usual rants, but only because authentication has occupied too much of my damn time this week.
Many years ago, we wrote a White Paper on OAuth with the team at OAuth.io who includes the amazing crew behind the APIdays events. It was called “The Standard That Isn’t.” We almost called it the 57 Flavors of Authentication, but we thought we might get sued. Still better than 50 Shades of Authenticattion.
Our position was that there were LOTS of REALLY ANNOYING problems with OAuth that made handling API authentication painful.
You’d have thought that in the last six years things might have got better. Sad to say, that they haven’t.
As this is a rant and not a technical piece, which will come in a few days when I have calmed down a bit and have had somebody more serious write it, we will look at some of the current issues of authentication, especially in the world of financial services and how they use OAuth.
As a bit of background, OAuth is how a lot of the API economy is secured, especially those parts where a user needs to prove who they are and use an authentication system so that some other third party can access it.
You’ll have seen this in many places like signing in to a service using Facebook, or authentication for your bank account against a money management application, and so on.
Basically, autthentication is a multi-directional handshake going on where the API sequence stops in the middle to take you, the user, to another service to say, ‘hi, this is me, yes let them in’ – tokens are exchanged and the service grants access for a period that could be as short as a single session, 90-day permission or effectively timeless.
It’s a good idea and well document and has been around for over a decade.
So, why I hear you ask, the rant about authentication?
Because it STILL DOESN’T WORK.
In preparation for some new services we’ll be launching monitoring Open Banking Standards (stay tuned, it’ll be amazing), we have been onboarding UK banks. Open Banking Authentication is even more complicated because we have another credentials exchange in the process using a signed JWT – the certificates for these can be issued by an entity like Open Banking UK or third parties for eIDAS certificates.
During the first few days of the process, we onboarded 18 banks. A few days to get 18 banks up and running. Ideal.
That was September 18.
It is now early November and we have managed to get 10 more done. Admittedly that isn’t working full time, but sitting around for our support queries to get lost/found/buried in soft peat for six months and so on before coming back to us ate up that time.
But here’s the thing – we probably still have another half a dozen banks left where we just can’t get authentication working AND they haven’t fully responded to our documentation clarification requests.
We’re starting to understand why so many users have problems with our product because it remains clear that despite five years of progress a LOT of companies building APIs still haven’t had anybody outside their organization actually try and use the bloody things from the outside or tried giving somebody the documentation and telling them to go and do it themselves.
And do not get me started on those banks out there who provide a PDF for their API documentation because we will be here all day.
Once more I see a requirement not just to rate APIs by their performance quality metrics as we do – and you should do, you know where we are – but by the soft metrics, the things critical to the success of the eco-system.
- Do you have documentation, and if you do, can another human read it?
- Have you got collections, mock servers, and all the other stuff a real human developer needs to work against?
- DOES IT WORK?
Authentication and security are essential, but seriously, people still need to be able to us