Microservice on top of an API

Question

I have an Odata API server that I can't change only access it, I can do CRUD operations on it. However I'd like to authenticate users, that are stored on this server. I can retrieve a user (his email, password everything necessary), now I'd like to authenticate him so I'd probably use JWT tokens. However as I said, I can't change the server implementation, so I thought of making a small microservice, that would have a login (/register) method talking to odata server and returning a JWT token.

Here is how I would imagine it:

My question is, is there a better solution ? Because this one seems like it's an API on top of another API. Also I still need to access the odata api to retrieve other informations I need. So this microservice would be used just for the authentication or should every endpoint first go through my API and then to OData API ?

Answer 1

Honestly, it's probably the only thing you can do. However, that doesn't mean it's a bad thing. What you are doing is abstracting away the Odata server from the application itself.

That allows you to change your OData server out for a completely different provider if you need to in the future without completely rewriting your application. I'm not sure what your particular Odata server is managing, but it is unlikely the only implementation of it. Chances are good that a replacement won't follow the OData standard since new standards will pop up from time to time (HATEOAS, etc).

Should I use the microservice just for the authentication or for every single endpoint though?

There is no one-size fits all answer here. Part of the answer depends on how authentication works with the OData server, and part of that depends on how much of the API you really need to expose.

Your decision may be forced depending on some technical details:

• Does every endpoint need to be authenticated? If so, you have to wrap everything.

I think it's a losing proposition to simply mirror an API in your own code. It's not an effective abstraction in that sense. I think there is value in only exposing the subset of API calls your application needs. As such, the microservice should expose application specific endpoints and translate them to the server behind it.

Bottom line is this: if you only need to authenticate a couple points, and you do intend to expose all functionality, only wrap what needs to be authenticated. Otherwise, only expose what your application needs to use in a way that is specific to your application.