Authentication and authorization as a central MicroService ASP.NET

Question

I am planning to change the ASP.NET Web API 2.0 which includes Authentication and Authorization and all the services into Microservices architecture.

My Question if I create a central microservice to handle authentication and authorization. How do I authorize the users sending the request with their tokens to other services?

To elaborate the question:

Let'say I have three microservices. 1 ) ASP NET framework handling authentication and authorization, Which will authenticate a user and sends a token. 2 ) Orders service, Which will receive the requests with the token in their headers. (ASP NET core) 3 ) Accounting service, which will receive the requests with the token in their headers. (ASP NET core)

How do we authorize the users when they call service 2 or 3? And Is this an ideal approach?

Incuse

your auth and authorization service will generate token jwt token likely. the token will be sent as bearer token to other services. your other services will validate the jwt token in their middleware. – Subsocial

See: docs.identityserver.io/en/latest – Raynold

@ImranArshad Thanks for the idea. I have my API is written in ASP.NET framework, which will generate the token using OAuthProvider and now I want to authorize that token in a different ASP.NET core service and get the userId from the token by which i can retrieve the data from the database. Is this possible? And if it is possible can you please direct me the steps involved or post me with an example article or document – Incuse

Answer 1

Based on comments Above

External Identity provider

You may need to use external identity provider e.g. identiyserver4 , azure ad or auth0 etc. Since the token may be generated is JWT token you will have to validate the token.

Validate Token

You need to validate the token in the .Net core Middle ware. Every token issued has a payload and your app middleware will verify every incoming token and reject if it's not able to validate. Your middle ware will fill the claims principle which can be used in your application to validate the authorization as well e.g. roles (if user has authorization to access particular api). You would put "authorize" attribute on top of controller and it will do the job.

You can validate the token manually or some identity provider gives automatic validation e.g. Azure Ad will validate the token and fill the claims principle without doing much effort by simply adding Azure ad nuget package.

There are heaps of example if you simply google. Tokens can be confusing so i would suggest you understand tokens e.g. id_token , access_token , refresh token . Authentication flows and claims. It would become easier if you understand the token types and flows. I am attaching very simple example just to give you idea.

Example

Subsocial

Just confirming, Do I need to replace my existing asp net web API identity provider to an external identity provider to generate JWT tokens which will allow my other microservices to consume and authenticate? If yes I need to write a new API (This time might as well use ASP Net Core API) to generate tokens. Is there any way that I can use the existing API to generate the tokens and going from now I can write new microservices? – Incuse

from question i assumed you have to write the system from scratch . if you are already using identity provider then you may use it. which identity provider are you using? you may have to share more details about your existing identity provider and how far you have gone in whole system and which parts are missing? – Subsocial

Answer 2

Instead of authenticating external requests at each microservice (you may want to do that for internal microservice communications), I would install a gateway (for example Ocelot which can handle the external "upstream" authentication for you using whatever system you're using, for example for Jwt bearer:

public void ConfigureServices(IServiceCollection services)
{
    services.AddAuthentication()
        .AddJwtBearer("TestScheme", x => ...
}

Then in Ocelot you can decide which routes require this scheme as follows

"Routes": [{
        "DownstreamHostAndPorts": [...],
        "DownstreamPathTemplate": "/",
        "UpstreamPathTemplate": "/",
        "AuthenticationOptions": {
            "AuthenticationProviderKey": "TestScheme", //<--here decide to use this scheme
            "AllowedScopes": []
        }
    }]

If Authentication is successful you can use Ocelot's method of "claims to claims transformation" from your upstream to downstream this method - I personally wanted customise this and build a new Jwt token for internal authentication so used my own downstream handler, like this:

services
   .AddHttpClient<IMyService, MyService>(client => ...)
   .AddHttpMessageHandler<MyJwtDownstreamHandler>();

//then in the MyJwtDownstreamHandler
request.Headers.Authorization = new AuthenticationHeaderValue(
   "bearer",
   TokenGenerator.Generate( //<--generate your own Symmetric token using your own method
       identity: myIdentity, //<--claims for downstream here
   )
);

Unblinking