Best API security method for my purposes

@_chris An API should require some form of authentication to use. It doesn’t really make sense for a web app to require authentication but then “native” apps like iOS and Android be able to use the API freely. If they can use the API without authentication, why can’t the web app…?

It might help if you explained more about your project, but in terms of authentication, Passport (and OAuth) would be the most appropriate given its flexibility. You would create OAuth clients for each, well, client that needs to consume your API (web app, iOS app, Android app, etc). Each client can then use the most appropriate grant for that client’s particular use case. So if your Android app doesn’t need to authenticate as a user, then you can use client credentials grant, which is suitable for “machine-to-machine authentication”.

Again, if you explained more about your project (and why your web app will require authentication but your native companion apps don’t for some reason) then we’ll be able to assist more.

Hi Martin, thanks for the reply. I can't discuss the specifics of the project but I'll explain a similar scenario:

The web app will require users to register and log in to use it. Users will upload images and tag them with some meta data. This data will then be saved to the database via the API. I guess here it could be a monolith Laravel app but I like the idea of separating it out to a Vue app and a back-end.

The other apps will simply call the API to retrieve the images and meta data. Users won't need to register to use this part of the service though I would like to protect the API from being called by anyone.

Note the webapp serves a different purpose to the mobile apps.

Another scenario:

Native apps call an API to send logs to to a server. The webapp is used for registered users in a view the logs. Here I wouldn't want the API to be called by anyone so an API token for each app would be ideal. So then oauth2 might be overkil?

Where you say You would create OAuth clients for each, well, client that needs to consume your API (web app, iOS app, Android app, etc).

Does this mean I'd have one client for every iOS and Android app or one for each instance of the app?

I think this might be where I'm getting stuck.

@_chris If you have an iOS companion app that uses your API, then you would create an OAuth client for that iOS app. Surely you only have one iOS app and not multiple apps…? Again, another reason why more context would come in handy.

Right thanks, that answers my second question. I gave a couple of example scenarios in my reply above. Do those both suggest oauth2 would be the best fit? Thanks!

@_chris Yes. OAuth is a flexible, token-based authentication system. You would use the client credentials grant I linked you to for the native apps if a user doesn’t need to authenticate and just the apps need to authenticate themselves against your API.

For the web app, create a client and use the authorization code grant with PKCE which is the most appropriate for that context:

The Authorization Code grant with "Proof Key for Code Exchange" (PKCE) is a secure way to authenticate single page applications or native applications to access your API.

It’s well worth reading the Passport documentation on the different grants available, choosing the grants that are most appropriate for your use case(s), and then how to request tokens and authenticate using the grants you’ll be using.

Thanks @martinbean

@martinbean just picking this back up as I'm finally getting around to implementing it!

As you adivse, I've started to implement the client credentials grant. I've created a new client for my mobile app. It's all working as expected from the Laravel side but one thing is bugging me.

To get the access token, I need the client secret. So I need to store that in my mobile app code (isn't that a security risk btw?).

What I'm stuggling to understand is what advantage this has over simply adding a hard-coded api token which is added to each request? I can then authenticate the api token at the server side. At least with the second option I don't need to worry about the token expiring.

Am I missing something?