I've been reading and searching for hours with no clear answer to this.

Imagine I have a SPA client hitting REST APIs, and they are served from the same service, e.g. I access my SPA by going to example.com, and the REST API calls that SPA makes are to example.com/api/orders. Do the SPA and the REST API need to be two separate OAuth client registrations?

Conceptually I'm logging into one app, but I can see how they differ. For example, the SPA needs a redirect_url after signing in and is a 'public client', whereas a REST API needs no redirect_url and can be a 'confidential client'. (I can see how it's also more flexible if down the line I want to open up the REST APIs to other consumers, and/or have the SPA call other resource providers directly).

I believe I could get away with one OAuth client registration, but is this an anti-pattern or heavily frowned upon for security reasons? I just want to throw up a simple SPA with some authenticated REST APIs on the same site, and needing two OAuth registrations seems like overkill.

CodePudding user response：

Conceptually, your frontend and the backend should be different OAuth2 clients. But yes, you can get away with one client.

From the security standpoint, it's probably better to have two clients. You can set different security constraints for each - require PKCE for the public client, disable the confidential client requests from outside of your network and such.

I would go with two clients. Even if you don't need anything special for either of them now, it may happen later and it's not much work to create an extra client.

There is another option - having just the backend client and using a session cookie for the frontend authorization.