Possible API authorization techniques on a fintech/banking app

user_1759069 0
Viewed 164

Let's assume that we've implemented a RESTful API providing financial/banking services and want to provide it to an in-house development team to implement the native mobile client-app.

In that sense the app and therefore the API will be public and reachable, so the WHAT gets access to it, needs to be authorized in every possible way.

The first solution that comes to mind is to provide a client_id and a client_secret and let the developers sign every request with the use of an Authorization http header: 

Authorization: APP client_id:base64(HMAC-SHA256(content, client_secret))

As long as the server "knows" the client's secret, authorization of API usage will run smoothly.

What I do not like about this:

  • every app instance out there has the same client_secret
  • the client_secret is irrevocable
  • it can be easily exposed through the app's source code even being obfuscated
  • all in all, possibility of getting requests from unknown sources

On the other hand I do not want to mess with user experience, with redirects and extra login requests like OAuth and such.

What other authorization techniques are there for this kind of apps? Which path for authorization do famous fintech/banking companies follow?

authorization rest api authentication security
1 Answers

Do not authenticate the app, authenticate the user or entity using it.

Endpoints like "register" that do not need authentication, well, do not need authentication. You can throttle access independent of an authentication too, based on networks the traffic is coming from, etc. This is usually done in the infrastructure, you do not have to have code for this.

In general, from a security standpoint, published clients should be regarded as user-controlled. I.e. the data they generate should be regarded as entirely user-controlled too, even if signed, obfuscated or whatever.

So far you didn't mention any use-case from the point of the backend, where authenticating the client software somehow would add value.

I did actually work on a banking backend which was accessed through an app and a web-ui (and several admin-uis). We didn't care which ui the user was using in the backend, we authenticated the user only. Things that did not need authentication (country lists, address/iban resolvers, etc.) were usable without one. I don't even know if the access was throttled or controlled in operation, it was not our job.

user_57667320
Related