ASP.NET Identity OAuth token string allows last character to be changed

Question

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

Answer 1

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":"[email protected]","sub":"[email protected]","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.