add cookie as an option for oauth2_introspection authenticator

[paulbdavis]

Proposed changes

Adds the ability to get the OAuth2 bearer token from a cookie in addition to header or query param. This allows an http-only, secure cookie to be used for storing oauth credentials.

Checklist

• I have read the contributing guidelines
• I have read the security policy
• I confirm that this pull request does not address a security
  vulnerability. If this pull request addresses a security vulnerability, I
  confirm that I got green light (please contact
  [email protected]) from the maintainers to push
  the changes.
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation within the code base (if appropriate)
• I have documented my changes in the
  developer guide (if appropriate)

Further comments

I'm not quite sure how to properly handle the schema files, I'm guessing there is some compilation going on there that is not documented (vs just editing the config.schema.json file as I have for now).

[aeneasr]

The schema process is a bit messy at the moment (for bc reasons). The way you solved it is correct!

I'm not sure if you are thinking about this use case, but just some points of warning:

1. We do not check if the cookie is httpOnly, thus, any XSS could set this cookie
2. There is no source authenticity (e.g. via signature verification), so anyone being able to set the cookie can set the token

The same of course applies to the other methods (e.g. me linking you to foo?access_token=.... or me doing an XSS that intercepts and/or injects the access token to API requests).

I'm saying that because many people think that cookies are "secure" and we should make sure to document this appropriately to avoid any misconceptions.

[paulbdavis]

I'm saying that because many people think that cookies are "secure" and we should make sure to document this appropriately to avoid any misconceptions.

@aeneasr I meant the "secure" flag is set on the cookie, not that cookies are inherently secure.

As with the cookie_session handler, the onus to protect against CSRF and XSS is on the application developer, not on oathkeeper, correct?

[paulbdavis]

For this and #302, I can also go ahead and add the same options to other oauth2 authenticator before it gets merged, just so those two are at feature parity

If that's the case, I'd probably combine this and #302 for both authenticators in another new pull request

[aeneasr]

Makes sense!

[paulbdavis]

Actually, after review, it looks like these options are not really appropriate for the client_credentials authenticator. I think this and #302 are ready to be merged as is