Security "audit" pre-analysis (based on rfc6749)

[aeneasr]

Hydra is in an early stage. There are multiple potential security issues that have not yet been considered or have been implemented wrongly. This is a list of (potential) issues, that need resolving before using Hydra in a production environment.

• rfc6749/AuthCode: If the client can be authenticated, the authorization servers MUST authenticate the client and ensure that the authorization code was issued to the same client.
• rfc6749/AuthCode: Authorization codes MUST be short lived and single-use. If the authorization server observes multiple attempts to exchange an authorization code for an access token, the authorization server SHOULD attempt to revoke all access tokens already granted based on the compromised authorization code.
• rfc6749/RefreshToken: Refresh tokens MUST be kept confidential in transit and storage, and
  shared only among the authorization server and the client to whom the
  refresh tokens were issued. The authorization server MUST maintain
  the binding between a refresh token and the client to whom it was
  issued.
• rfc6749/RedirectURI: ... the authorization server MUST
  ensure that the redirection URI used to obtain the authorization code
  is identical to the redirection URI provided when exchanging the
  authorization code for an access token. The authorization server
  MUST require public clients and SHOULD require confidential clients
  to register their redirection URIs. If a redirection URI is provided
  in the request, the authorization server MUST validate it against the
  registered value.
• rfc6749/ResourceOwnerPasswordCredentials: The authorization server and client SHOULD minimize use of this grant type and utilize other grant types whenever possible. This has to be fixed here
• rfc6749/GuessingAttacks: The probability of an attacker guessing generated tokens (and other
  credentials not intended for handling by end-users) MUST be less than
  or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).
• rfc6749/CSRF: The authorization server MUST implement CSRF protection for its
  authorization endpoint and ensure that a malicious client cannot
  obtain authorization without the awareness and explicit consent of
  the resource owner. Please revalidate front-end workflows.
• rfc6749/ClickJacking: To prevent this form of attack, native applications SHOULD use
  external browsers instead of embedding browsers within the
  application when requesting end-user authorization. Make this an explicit note in the README
• rfc6749/ImplicitImpersonation: Any public client that makes the assumption that only the resource
  owner can present it with a valid access token for the resource is
  vulnerable to this type of attack.
  This type of attack may expose information about the resource owner
  at the legitimate client to the attacker (malicious client). This
  will also allow the attacker to perform operations at the legitimate
  client with the same permissions as the resource owner who originally
  granted the access token or authorization code.
  Authenticating resource owners to clients is out of scope for this
  specification. Any specification that uses the authorization process
  as a form of delegated end-user authentication to the client (e.g.,
  third-party sign-in service) MUST NOT use the implicit flow without
  additional security mechanisms that would enable the client to
  determine if the access token was issued for its use (e.g., audience-
  restricting the access token). This is should be avoidable by implementing OIDC and informing client developers

Please be aware that not all of the items above affect Hydra. This is just a list of things that have to be reviewed.