Using OAuth2 for securing a monolith private REST api?

Question

Maybe this question seems opinion based, but I am facing a hard time in deciding to secure a RESTful API.

Firstly, my use-case:
My application is pretty straight forward: The front-end is written using React.js(for browser client) and that will consume the RESTful API for getting its data from the database(or something). The API is built using Spring framework.

This API is not a public API, and it has only a single client(as of now, later would be mobile apps).

Now lets come to the security problem. Obviously, I want to secure my API, I am using Spring-security as a tool for this job. During the starting days of learning, I knew only about the Basic-Authentication. But, when I kept on reading about more secure options, I learned some new fancy terms:

1. Token-based Authentication, using JWT
2. OAuth2
3. OpendId connect

When I read more blogs like from Auth0, Okta and a lot more, I messed up everything. This made me think twice if I should use OAuth for securing a REST API (which is not public). Also, almost all of the blogs about OAuth take examples of social logins. This made me more messed, that OAuth is for giving access of your API to the third party application. And that's it, not for my use-case.

I then asked some experts from some channels and blogs, some said the Basic-Authentication is very enough for security(using https) and I should avoid OAuth for such a small requirement. Other said opposite to that, saying Basic-Auth has security vulnerabilities.

Let's consider that OAuth is perfect for me, but in that case also, where would my Authorization server reside? Because tutorials only explain about Authorization server by keeping their code in the same layer. No separate project or something.

JWT also has some negative reviews for my user-case:

1. they cannot be revoked, will only expire on its own. Isn't it insecure?
2. they are massive in size, compared to session token or cookie
3. hight computational cost for verification

I really need some more advice on this, it has already taken my lot of weeks.

Thanks.

Answer 1

The real answer depends on information not in your question. For example do you need identity verification or are you just authorizing API access?

OAuth and Open ID Connect (OIDC) today are basically the same thing for most services such as Google Login. OIDC adds an identity layer on top of authorization. If you need to verify the identity of your users, log their activity, control resources per user, etc. this is your solution.

For authorizing API endpoints, there are many solutions. The most common are secret key value and JWT. Secret key has many weaknesses so I will not touch on that here.

A very common method of authorizing API endpoints is using JWT tokens and the Authorization: Bearer TOKEN HTTP header. I will now try to answer your concerns about using JWT tokens. Here I only refer to Signed-JWT tokens.

they cannot be revoked, will only expire on its own. Isn't it insecure?

JWT tokens can be revoked by revoking the signing certificate. This would require creating a certificate revocation server, so this is not so common. An improved approach is to create short-lived tokens. Typical expiration time is 60 minutes (3600 seconds) but you can create tokens for any time period. When the token expires, the client requests a new one, which your backend can authorize or refuse.

they are massive in size, compared to session token or cookie

What is massive? You can create a token of any size from just a few bytes (the size of the signature plus data) or include extensive information in the token. Unless your tokens are out of control in size, this will not matter to most implementations.

high computational cost for verification

Again you are using a vague term. Verifying a Signed JWT is not computational expensive unless you are on tiny devices such as IoT (which are already using SSL certificates, encryption, etc.) or you need to handle millions of transactions per minute. In other words unless you have a solid reason to worry about CPU cycles, don't worry about them in regards to improved security.

Let's consider that OAuth is perfect for me, but in that case also, where would my Authorization server reside?

Your OAuth 2.0 authorization server can reside anywhere you want. Implementing OAuth is very easy and there are many libraries to manage the details for you. Your authorization server can be part of your backend, be a separate server, etc. You can even just outsource this completely to identity providers such as Google Login, Auth0, Okta, etc.