oauth2: allow access token validation for public clients

[aeneasr]

As @ericalandouglas pointed out in gitter, there is currently no way for public clients to validate access tokens or, at least, get the contents of the at_ext claim. There are a couple of reasons why this currently doesn't exist:

1. Token introspection as per rfc7662 does not allow unauthorized access
2. Warden validation is targeted at resource servers, which are always confidential and thus can authorize themselves
3. An unprotected token validation endpoint can lead to token scanning attacks, where an attacker tries out different tokens using dictionary or brute force attacks. This is the reason for disallowing unauthorized access to 1. and 2.

I checked out what google, amazon and github are doing. This is a nice sum up: http://stackoverflow.com/a/20010178

• Google: https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg
• GitHub: GET /applications/:client_id/tokens/:access_token
• Amazon: https://api.amazon.com/auth/O2/tokeninfo?access_token=Atza|IQEBLjAsAhRmHjNgHpi0U-Dme37rR6CuUpSR

I personally like the GitHub way, because it allows us to check if client id == audience. However, it looks like the big ones decided to go for tokeninfo.

I appreciate feedback on this.

[ericalandouglas]

Thanks for making this issue @arekkas. I like Github's way as well for the added security around audience verification but Google/Amazon's way is sufficient. The at_ext claim is the only token claim I currently envision this endpoint returning as I am not doing validation, just data introspection.

[aeneasr]

@ericalandouglas as you correctly suggested, this is a great place for OIDC, as you are only interested in meta-data. I don't know why I didn't think of this before. I will still keep this issue open, just in case.

[ericalandouglas]

@arekkas that is correct. OIDC should be sufficient for my use cases, thanks for helping me figure all this out!

[aeneasr]

Actually, there is no standard way to validate access tokens with public clients, without being at risk of token scanning. Therefore, I'll close this issue until someone comes along with a good use case and ideas how to mitigate that risk.