1

We have a microservice backend system & we expose APIs for our customers to use. We are now developing our Authentication system with our identity provider service.

We have a customer(a company), their users using their service via their mobile app. In short, they are a B2C business. This company would like to have their users be able to also access our service in addition to what their mobile app is serving. Their users need to login to the mobile app with registered credentials in their backend system.

I am seeking for a best solution for this business case following OAuth2+OIDC standard.

From my team's perspective, we would like to know who is accessing our API & issuing tokens for every access to our APIs. In other words, we'd like to identify every of their user who is accessing our API. But their users don't have credentials in our system but only in that company's backend system.

At the moment I have two rough directions:

  1. Their mobile app don't directly access our API but via their backend.
  2. Their mobile app can directly access our API.

I am not sure which option is better(secure & reliable & performant) & how the flow should look like. Could someone please suggest me the best authentication and authorization flow for this business requirement that needs to access our APIs?

user842225
  • 61
  • 3

1 Answers1

1

I encountered this before and I think I can give my 2cents.

I think both is good if you implement it properly, but I personally prefer backend->API since it will be behind several layers of security (their app's security -> their backend -> our backend API which can be protected by IP whitelist, mTLS, etc) and the development effort is (arguably) less than the alternative.

That being said, as you have stated, the performance cost may be an issue for you. It really depends on your situation.

You may have to consider a few things:

  • The amount and volume of the requests done
  • The type of requests done (eg: the existence of sensitive data and whether there are regulations/standards that you need to be in compliance with)
  • The security of the company
  • The performance and its cost
  • Who can support the dev and maintenance effort for this integration
  • The reusability of your TBD auth system

Btw after the integration, make sure you do a pentest on the company's mobile app that you will be integrating with. Some companies have no regards of security at all

Waristea
  • 21
  • 3
  • Thanks! You hold valid points. I actually also wonder the flow with your suggestion. That's from their backend to our backend. I mean what request payload to expect from their backend to our backend in order to authenticate the access from their user? How the token our backend issued for their user is send to their user? Should our backend send token for their backend and their backend issue token to their user based on our token? Things like that flow is actually my concern. It would be nice if you could share your thoughts on it. – user842225 Mar 25 '22 at 21:31
  • 1
    @user842225 CMIIW, IMO it depends on the amount of companies that you are integrating with. If you dont have a lot of companies connecting to your server and there is a large degree of customization between companies, you can use a more manual method to suit their needs. For example, maybe just exchange your public cert through email and build from there (set up mTLS, IP whitelist, and send via email the encrypted API-key using the cert). – Waristea Mar 26 '22 at 15:59
  • If you have lots of companies that will connect to your server (eg if you are a payment Gateway like Stripe) and there is only a small degree of customization, you can create a public dashboard that companies can login and register to. There, you can put the API Key that they'll use to. – Waristea Mar 26 '22 at 15:59
  • btw if you want this answer quick, you can use Reddit. The community is much larger there – Waristea Mar 27 '22 at 21:10
  • Simple reply to comments above, I have only one company to integrate. And it has to follow the OAuth2+OIDC standards as best as possible. That's the business requirements. The API key solution is not to be considered since it is not the mechanism of OAuth2 , in general I know we need to follow "Client Credential Flow" from OAuth2 but not sure for this particular case what is the concrete integration flow within the "client credential flow" context of OAuth2. – user842225 Mar 28 '22 at 13:39