4

Using ASP.NET Identity, WebAPI, and UseOAuthBearerTokens

public void Configuration(IAppBuilder app)
    {
        app.UseOAuthBearerTokens(new OAuthAuthorizationServerOptions
        {
            AllowInsecureHttp = true,
            TokenEndpointPath = new PathString("/token"),
            AccessTokenExpireTimeSpan = TimeSpan.FromDays(1),
            Provider = new CustomProvider(...))
        });
    }

The API returns a token string upon a valid login request. The token works correctly and gives the end user access to authorized portions of the API, however, if the final character of the token string is altered it sometimes still works. It appears that this is only the case for the final character of the string and only some values/alterations still allow the token to be valid. Why is this the case? Is this a problem with the code or just part of Identity?

For Example: The token returned from the server is

mdC0XvL4VBucyMPD-OvQ0KA5vW1Q8OHdF4OtqET5hEFI20uaOXbX4JlzTwkLRmWUr-4cIzQf1adXx5DbnXltuwcSjiX1NEY5DqhS3c9GyU1c2VqLAOUYj4-BraaheNsCPvReZqvT__NsObpziKX98SY4gSUGDBVigVONdvlpRunzPZlIeJh99jBqzavuo4qSEElAlBNvNFts95aN7otO5-bNiDNl1t_CP9PQWcTIipMNe_No2J8wGbmIvEWCBAhN3Ts6lvmFpHSA02up1YykZoDZa0TZY7QOt187aP9-7kN

You could change the N (at the end of the token string) to an O or a P and it would still allow the user to access the API

Hunter LaTourette
  • 41
  • 1

1 Answers1

4

Rightio, so here's another answer after my previous one was deleted.

Someone from Microsoft more clued up on JWT fed back the following.

Sure – so JWT is in three parts, separated by a '.' character
If I base64 decode that one it will say:

{"typ":"JWT","alg":"HS256"} {"unique_name":"x@y.z","sub":"x@y.z","iss":"https://x-y-z.azurewebsites.net/","aud":"Any","exp":1506047645,"nbf":1505442845} яE7Sa( PƙAa)ʗ3?g[

The first part is the algorithm type, the middle is the claims and the last is the key They key – it doesn’t matter if you play with it and it still decodes… changing the last char there must be an unused character.

You can’t fake the claims by doing that… What really does matter is if you can change the claims – change anything between the two middle .’s and then it will stop working.

My takeaway is that changing the key doesn't affect the security/integrity of the token. The system decoding the token will either decode it successfully or not at all, with or without tampering. You will not be able to hijack a session nor does it represent a vulnerability.

jamesaarondevlin
  • 41
  • 5
  • it seems to me that it does increase the likelihood of being able to guess a token, ie - hijack a session. ..but that the likelihood is still very small. also, that can be mitigated by adding additional entropy to the token to make it longer. (adding additional data (real or padding), using a different encoding algorithm, etc.) https://connect2id.com/products/nimbus-jose-jwt/algorithm-selection-guide – James Earlywine Jul 03 '19 at 18:20