OAuth2 for REST API with tightly coupled SPA as only client

Question

I'm developing a REST API with a tightly coupled SPA as the only client of the mentioned REST API.

Let's say the SPA is available at myservice.com and api is under myservice.com/api. They're basically one service, just split at code level, and deployed at different root paths.

What I'm using for security right now is OAuth2 with ROPC (username/password) grant type.

Here comes the problem. I keep reading everywhere that ROPC is not secure and should not be used. What should I use then?

My REST API acts as an authorization server but it doesn't have any web interface itself. So any flow involving redirect doesn't really make sense. The SPA and API are so tightly coupled that for an end user they're basically one application. There's no 3rd party.

I could add simple login form to the API available at let's say myservice.com/login. But I'm struggling to see the difference that would make.

Security in this application is very important.

Here are my questions:

Is using ROPC really dangerous in this scenario?

What would be the perfect way for authentication and authorization?

Or maybe OAuth2 is completely redundant without a third party?

Technologies used:

Server: Spring Boot

Answer 1

Is using ROPC really dangerous in this scenario?

No, not really providing:

a) You don't store a user's password - maybe only use it to get the initial access and refresh token - although that could be tricky with an SPA.

b) Your SPA client and the resource API are owned by you, so you don't need the user to consent to specific scoped access for the SPA.

What would be the perfect way for authentication and authorization?

It depends on lots of things. Not enough info to try to answer that. OAuth2.0 (with a probably implemented Authorisation server) is a pretty good way for the example you have here.

Or maybe OAuth2 is completely redundant without a third party?

If other applications will use your API in time then OAuth2.0 is probably a good call. Otherwise you could probably use a more simple solution e.g. session cookies as all sits on same domain.

Answer 2

Answer to this can be taken out from OAuth 2.0 specification (RFC6749) itself. It define when ROPC grant is suitable for,

4.3. Resource Owner Password Credentials Grant

The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application. The authorization server should take special care when enabling this grant type and only allow it when other flows are not viabl.

According to your explanation, you have tight coupling with SPA and backend. Also you have both authorization server and resource server built as one. This is completely acceptable implementation.

The authorization server may be the same server as the resource server or a separate entity.

So what matter now is to clear out why you use OAuth 2.0 in your scenario.

If you are using OAuth 2.0 to obtain tokens, maintain them as defined through OAuth 2.0 specification, then this is completely oaky. But if you are doing this to follow a trend, think twice.

OAuth 2.0 implementation comes with it's own complexity. You have to maintain user identities, maintain tokens and renew them. You are building a complete authorization server by yourself. But this also have some advantages as well.

For example, same authorization server can be used to issue token for future integrations/secondary app. IMO, usage of OAuth 2.0 make integrations easy as it define a protocol for issuing tokens, renew and revoke them.! But in such integration scenario, may be you will require to use a different grant. Still, your API being authorized on token, you only need to worry about how new integration/application obtain tokens. This is better than using authenticated sessions

Going back to your questions,

Q : Is using ROPC really dangerous in this scenario?

As explained, if there is a correct trust relationship between client and authorization server, then it is fine. But be mindful about complexity comes with having a authorization server.

Q : What would be the perfect way for authentication and authorization?

OAuth 2.0 is for authorization. You obtain access token and use them to authorize against your protected APIs. From APIs you do a token validation to detect correct access levels/permissions.

If you want authenticaiton, then you must use OpenID Connect. It is a protocol extended from OAuth 2.0. And allows your application to authenticate the end user based on ID Token. You can use ROPC grant to obtain an ID token.!

Q : Or maybe OAuth2 is completely redundant without a third party?

Not necessarily. It allows you to design your APIs in a modern, standard way. Who know what future hold (again the integration scenario). Following a protocol allows that easy.

Only advice, follow specifications closely. Do not invent your own protocol/adaptation. It makes things harder to maintain.