OAuth Bearer Authentication - Reject invalid token

Apr 3, 2014 at 8:49 AM
Hello, I am trying to adjust my application to reject invalid (plainly wrong or expired) access tokens, but I am not sure where to add the code best.

After digging through the code I found out that in OAuthBearerAuthenticationHandler it will parse the token using a fallback mechanism when the provided AuthenticationTokenProvider did not parse any ticket (like the default implementation). This handler will log a warning when the token could not be parsed to any ticket or when it expired.

However, I can't find any place to plug in my own logic to what happens when the token is invalid or expired. I could theoretically check this on my own in the AuthenticationTokenProvider, but then I would have to reimplement the logic (= copy it over) for creating and reading the token. Also this seems just out of place, as this class seems to be only responsible for creating and parsing tokens. I also don't see a way to plug in my own implementation of the OAuthBearerAuthenticationHandler in the OAuthBearerAuthenticationMiddleware.

Apparently my best and cleanest shot would be to reimplement the whole middleware, but this also seems very overkill.

What do I overlook? How would I go on about this the best?
Apr 13, 2014 at 11:22 PM
Hi MartinJ87,

I think there is not a direct hook, but perhaps implementing your own SecureDataFormat, that cares for decrypting the received token, would do the job. This SecureDataFormat could delegate to the original DataFormat and fire an event, when the token cannot get decrypted or has some invalid properties. You can register your DataFormat as an option when you register the middleware.

Wishes,
Manfred
Apr 14, 2014 at 10:53 AM
Hey,

Take a look at OAuthBearerAuthenticationProvider and its ValidateIdentity method: from there, you have a full access to the validating context and the deserialized identity. This way, you can send back any error using context.SetError('invalid_grant', 'message') if the deserialized identity doesn't meet your security requirements. While you shouldn't repeat validation steps already done by Katana - integrity and freshness of the token - you can of course query your database to determine whether the access token or the authorization used to issue the token has expired or not.

Good luck.