Why should I follow Oauth2.0 and OpenID Connect Protocole instead of basic authentication with just a JWT when I fully trust the relying party?

Question

I'm currently working on a project using microservices for the first time. Here is the architecture I came up with:

1. A Laravel Web Application Server
2. An Api Gateway
3. An Authentication server
4. Protected Micro Services

First I thought about using Oauth 2.0 and OpenID Connect Protocoles, with the Laravel Web App Server being the Oauth 2.0 Client ( OpenID Connect Relying Party ), and the protected microservices being the resource servers.

Oauth 2.0 is for authorizing access to protected resources, using an access token ( and a refresh token optionally ) and the OpenID Connect is an authentication protocole built on top of Oauth2 in order to provide third-party clients with access to basic user data ( through the user-endpoint ) and allow them to verify the user identity, and it uses ID Tokens, which contains claims about the user, unlike the access token who does not have any information about the user.

---

That is clear and understandable for the case where clients are third-party applications, but when the client is a first-party application, like a Laravel web application that I am developing for example, I am a bit confused about how I should approach the authentication procedure. I have two options, so please let me know if I am misunderstanding something.

Option 1: Implementing the Resource Owner Password Grant Flow ( Following the Oauth 2.0 and OpenID Connect )

I can use this flow since the client ( The Laravel Server ) is not a third-party application and can be trusted with the users credentials, so basically, the flow is like the following:

1. The user enters his email and password, which are sent from the Laravel Server to the Auth Server through the API Gateway.
2. Auth Server returns an Access Token and an ID Token.
3. When the user tries to access resources available in the protected resource servers ( micro service 1, 2 and 3 ), the request is sent from the Laravel Client to the API Gateway and before it's sent to the micro service, the API Gateway forwards the request to the Auth Server to validate the token.
4. If it's valid, the request is sent to the target micro service, with the ID Token and the micro service can identiy the user.

Option 2: Using only one JWT Token.

This one seems easier to me and makes much more sence than implementing OpenID Protocole and Oauth 2.0 by using the Resource Owner Flow.

The user tries to log in, the request is sent to the Auth Server. The Auth Server returns a JWT Token containing informations about the user. Then requests are sent directly through the API Gateway to the micro services.

---

Maybe I am misunderstanding something but if I am not and the two options are possible, my question is why bother following the resource owner password credentials flow if you trust the OpenID Connect Relying Party ( Oauth 2.0 Client ) with the user credentials. Why not just provide it with a token that has user informations instead of an access token and an id token ? Maybe it's a more secure approach ?

I look forward to some clarifications.

Answer 1

Following standards gives you a few advantages. First, you're less likely to have your security breached, as the standards are created with some common attack vectors in mind. Secondly, if you use standards to communicate between your services, it will be much easier for you in the future to exchange any elements of your system. If, at some point, you should decide that the Auth Server you created is not enough, and you want to exchange it with a product from the market, it will be easy, if you use OAuth and OpenID. Should you use a protocol that you came up with yourself, you will have some hard time changing the server.

Another thing is to have clear boundaries of concerns for your services. If I understand correctly, in the second approach, it will be the Web Server that will perform authentication and the Auth server will only issue tokens, right? If the Auth server will also perform authentication, then it's pretty much the same as using ROPC - the only difference might be the names of parameters. But if it is the former case, then you start mixing concerns - the web server becomes responsible for authentication, which may complicate things in future.

If you're building a small system, which you know will not be expanded, then using ROPC is enough (still it's good to follow standards for security reasons). If you think that the system might get bigger in time, it's important to have concerns separated and follow standards, or you'll end up with a unmaintainable and insecure system.

Have a look at these resources about Neo security and security maturity models, where you can read some more about how to architect a modern security platform.