Develop Reference

How to Validate Token JWT Token that it comes from the same User in Web API C#

Recently built JWT token using web API Core. Just need serious clarification below are the details
If User A is logged using browser tab A and request has been processed and token is generated. If User B is logged using browser tab B and request has been processed and token is generated. What will happen if i sent User A token to User B How to validate the token that this token is for this particular logged in user ?

I think you might be misunderstanding the way Authentication work generally.
In JWT Auth, 'logged in' simply means that the request you're making contains a valid Bearer token. This means that the user that sends a valid token is always the valid logged-in user and there is no need for any further validation.
If however, you need further information based on the Authenticated user, you can access that information from the HttpContext or the ClaimsPrincipal property in your controller named User.
For example,
string accessToken = await HttpContext.GetTokenAsync("Bearer", "access_token");
string userName = User.FindFirst(ClaimTypes.Name).Value;
NB: You must explicitly store claims that you'd love to retrieve from the User property.

ASP.NET Core: JWT token with Scopes

Background
I have a ASP.NET core (v2.1) project that contains an API. This API is access restricted by JWT bearer.
My server expose an endpoint for login:
POST http://example.com/api/login
After attaching the token to the request, I can call one of the server methods (GET or DELETE:
GET http://example.com/api/1234
or
DELETE http://example.com/api/1234
Target
I want to implement "another type" of token that will allow access only to specific scope. Let's say that we want to give access just for GET method. So, if you have this token - you can GET the resource but not to DELETE it.
Wondering if this is possible with JWT bearer token? If yes, how?
Thanks!

You shouldn't do this with the token itself. The token is used to authenticate that a user is who they claim to be. You should instead look at using the roles to authorise an action and assign different users roles to restrict access to delete verbs.
This article should be able to explain further
https://learn.microsoft.com/en-us/aspnet/core/security/authorization/roles?view=aspnetcore-2.1

JWT Bearer token should be used for authentication mechanism but what you are talking about is Authorization and thus your approach is wrong seems. You should rather use the Authorization pipeline and implement proper Roles/Policy based authorization which will restrict access to those Api endpoints.

How to invalidate or destroy jwt default token as external bearer in c#?

I am using web api and implemented default behavior for login i.e. endpoints using jwt authentication and now I am facing issue in invalidating or destroying jwt token as I want to implement logout functionality.
Can anyone suggest the logic for this situation how to deal with JWT tokens expiration?
Note: For login GrantResourceOwnerCredentials method is used as usual and it creates the token for authentication purpose.

Once you have issued your token it will be active until it expires.
If you need to perform a logout or 'invalidate' the token you will need to perform an extra step.
What you could do is store a SessionId (that is a guid) in the db on the User table. When a user logs in send the session id alongside the beader token. Store this session id in a cookie or in sessionStorage or whatever and send it up to the server with each request. Then you can have a filter applied globally to every action that checks the SessionId sent up from the client matches the SessionId stored in the database.
Then if you need to invalidate the token then store a new guid SessionId in the user table, when the next request comes it won't match and you can return a 401 response.

If you want to invalidate certain tokens, you need to store the tokens you give out in a database.
Then you check against those tokens when you validate the incoming token.
When you need to invalidate one, just delete it from the database.

How to get application profile data into access token?

I'm using IdentityServer4 with a mix of v4/v3 clients.
I have custom profile data that is store on the application side that I'd like to include in the access_token so that my downstream APIs can use this with bearer/jwt authenication.
I understand I can manipulate claims via IProfileService, but that is registered on the identity side, not the application.
How can I get my custom profile claims into the requested access token?
Additional Details
I've done a proof of concept using Extension Grants to specifically pass my application claims through the IdS so that it includes those in the token. It works...but feels pretty hacky.

Please do not do that. The JWT token is sent with every request.
if the downstream API needs something from the user, then either submit it with the call, or have an endpoing the downstream api can call. Embedding rarely used large inforamtion in someting transmitted every call (except in http 2.0) is a nonononono.

You can not change jwt token content after being created and signed by authorization server. But you can use ClaimsTransformation to manipulate claims on the api project.
Edit: Another option to use JwtBearer OnTokenValidated event.

Any claims issued from your implementation of IProfileService should end up in the token.
Note that your implementation of IProfileService should check if it is issuing claims related to IdentityResources or ApiResources. It would be a bit pointless adding api claims to an id_token.
When the client receives the token from you IDS, it will pass it in calls to your API.
If your client is using cookie authentication, the tokens themselves as well as some user profile claims will be stored in the authentication cookie. This obviously depends on the flow your are using Implicit, Hybrid etc.
If you want to inspect what you get back from the IDS at the client you could add a Cookie Authentication Event handler (eg OnValidatePrincipal) to see whats stored in the cookie, or add an OnUserInformationReceived event handler to your OIDC handler and inspect what you get back in there.

Asp.Net Core - Custom Authorization and Identity from another server?

I'm trying to figure out how to configure/use the Asp.Net Core Authorization with the credentials and user data in another server, accessed through an API.
For example, in the "Auth" server, we have the Auth database, that stores users, roles and claims. Some examples:
GET https://auth.myserver.com/v1/users/4/IsInRole/Admin
The response is a simple bool.
Or:
GET https://auth.myserver.com/v1/users/4/GetRolesForUser/
The response is a list of roles.
The another server is the resource server (also entirely API based, no front-end). It stores a lot of data that demands authorization by roles and claims.
Also, we have a third player: the client.
The client will:
Ask the auth server to get a bearer and a refresh token, using an username and a password
The client stores those tokens and send the bearer to the resource server to get some data
The resource server will ask the auth server if the bearer token is valid
If it is, then the resource server needs to ask the auth server again about the user that has that bearer token, and if that user has the necessary holes/claims that are necessary to access the requested resource.
The 4 step is my doubt. I imagine that should happen on the resource server controllers:
[HttpGet]
[Authorize(Roles = "Admin")] //API CALL HERE TO THE AUTH SERVER (?)
public async Task<IActionResult> GetData()
{
...
Basically, I don't know how to Authenticate an user on the context (just until the request is returned), putting it in the HttpContext.User, using my own custom validation process.
I've tried to simplify this architecture as much as possible to make my question more clear. Please forget about the security on the "Auth" server.

If you are using jwts this flow can be simplified roles can be stored in claims which means that no api call is needed in the authorise attribute.
Also the resource server doesn't need to verify that the token is valid that can be done using a secret.
Look into thinktecture the following are good resources https://leastprivilege.com/ and https://brockallen.com/