Asking for Alternative API Authentication

Currently, the Monzo API uses standard OAuth 2 confidential client authorisation flow, which would make sense if the Monzo API was designed for companies to have one app with thousands of users, which I assume the Monzo API was originally intended to support, but we’re 7-years post-“but we are not going to expand the scope of the APIs or allow developers to publish their applications, yet.”, so I assume that’s not going to happen, ever (especially given that companies have Open Banking APIs).

So, I’d to see Monzo concede and move the design of the API towards making it easier for people making personal use scripts, dashboards and apps. And for me, the biggest problem is authenticating to the Monzo API. It’s not really that hard, but it requires the end application to bundle:

  1. an oauth2 client
  2. an entire web browser the user can log into their email on
  3. and storage & authentication logic durable to always store the latest refresh token.

This is a pretty big (or impossible in the case of Arduinos, ESPs, PiPicos and the like) ask for what I assume is the majority of people building with the Monzo API, instead, it would be much simpler if Monzo had support for a mechanism that used long-lived secrets.

The easiest way to authenticate with the API would be just be able to go to the developer portal and create a personal access token and hard code that into whatever. The security of this is a bit mhhhh, but I mean, if I can create a GitHub token with the ability to push ransomware to prod or an Entra Service Principal with the ability to nuke the entire Azure subscription & 365 domain, that mechanism should be good enough to get read only access to my sausage roll habits. Maybe use JOSE or certificate based OAuth2 client credentials?

But, I’ll admit, I’m not entirely sure of the legislation around this so I wouldn’t be too surprised if this isn’t something that’s a hard ‘no’.

As a side note, something I’d also like to see is web-push-protocol support as an alternative for webhooks. Primarily out of selfish laziness because I don’t want to have to write my own proxy server, when there’s already support in browsers, and existing proxy servers for iOS and Android apps.

4 Likes