What are the payload requirements for ASP Net Identity JWT API tokens

Question

I have an ASP.NET Web Api that uses ASP.NET Identity to manage user and role access to the API. I have a case where I am trying to create a JWT token so an external company can reach one of my endpoints. I have been trying to create my own JWT using the code shown in this SO article - Second answer. My JWT token is decoding properly but does not allow access to my endpoint even though I have the proper role assigned. I am wondering if perhaps other information is required in the payload because the system is based on ASP.NET Identity.

Here is the payload that I included in my JWT

{
  iss: "http://mycompany.com",
  name: "Company Test",
  role: "CompanyTest",
  aud: "<Audience ID of my application>",
  exp: 1485433642
}

Here are some payloads that I left out of my JWT creation that are included in the JWT tokens generated by ASP.NET Identity. I am wondering if they are essential and therefore must be included in the payload of the JWT.

{
    "nameid": "<user unique identifier here from Identity table>",
    "unique_name": "<Email account of user>",
    "http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider": "ASP.NET Identity",
    "AspNet.Identity.SecurityStamp": "<Security stamp column from Identity table>"
}

I left these values out when trying to create my own JWT token because the I was not tying the access to a specific account. I just wanted to create a long lasting token that the external company could use without having to log in.

While you may be decoding the JWT you still need to apply the identity to the context of the request. which is what the libraries do for you. Once you decode the token extract he information you need, create an identity and apply the claims and assign the principle to the current thread. You can abstract all this functionality in an action filter — Nkosi, Jan 16 '17 at 18:13
The whole thing I am trying to avoid is forcing the external company to validate through a username and password which is the normal flow of my API access. I suppose I could create and account for the company login with the credentials and the change the expiration of the JWT issued and then resign using my secret key. — webworm, Jan 16 '17 at 18:18
I was planning on sending them the token in a secure email. They would take it and place it in the header of their API call to my endpoints. — webworm, Jan 16 '17 at 18:25
the problem with rolling your own security is that there are soooooooo many ways it can go wrong. what would be the life span of that token? given that you have to create it, then email it to them and then they have to use it before the token expires. — Nkosi, Jan 16 '17 at 18:28
@Nikosi .. you make a good point and the best way to accomplish this would probably be to use refresh tokens, But the business rules of this situation specify that the external company should not have to logon .. ever. By making the expiration data far into the future they will have time to implement it. When I need to revoke access I can remove the role from the database. — webworm, Jan 16 '17 at 18:33

score 1 · Accepted Answer · answered Jan 16 '17 at 18:30

I figured out the answer to the question so I figured I would post it here. You do not need the extra payload object. Turns out the issue I was having was the iss: payload. I had set it to a production environment but was testing locally. Once I changed the iss: http://localhost:12345 I was able to access the endpoint even though the user was not in my ASP.NET Identity system.

So just to confirm .. all I needed was the following data in my payload

{
  iss: "http://localhost:12345",
  name: "Company Test",
  role: "CompanyTest",
  aud: "<Audience ID of my application>",
  exp: 1485433642
}

What are the payload requirements for ASP Net Identity JWT API tokens

1 Answers1