PKCE "pixy" / RFC7636

[i4mi]

Implement proof key for code exchange in order to prevent session thievery.

According to https://tools.ietf.org/html/rfc7636

TODO:

• Create verifier
  code_verifier = high-entropy cryptographic random STRING using the
  unreserved characters [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~"
  from Section 2.3 of [RFC3986], with a minimum length of 43 characters
  and a maximum length of 128 characters.

• Derive code challenge from code verifier (e.g. SHA256 or plain).

  The client then creates a code challenge derived from the code
  verifier by using one of the following transformations on the code
  verifier:

  plain
  code_challenge = code_verifier

  S256
  code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))

• Send code challenge with the authorization request.
  Note: At this point also the state param needs to be considered (see issue #3 ).

  This includes the following additional parameters:

  code_challenge
  REQUIRED. Code challenge.

  code_challenge_method
  OPTIONAL, defaults to "plain" if not present in the request. Code
  verifier transformation method is "S256" or "plain".

  The server stores the code information internally.

• Upon receipt of the Authorization Code, the client sends the Access
  Token Request to the token endpoint. In addition to the parameters
  defined in the OAuth 2.0 Access Token Request, it sends the following parameter:

  code_verifier
  REQUIRED. Code verifier

  The "code_challenge_method" is bound to the Authorization Code when
  the Authorization Code is issued. That is the method that the token
  endpoint MUST use to verify the "code_verifier".

• Server Verifies code_verifier with stored challenge information.

  BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge

  If the "code_challenge_method" "plain", they are
  compared directly, i.e.:

  code_verifier == code_challenge.

• Upon success, the server issues the access and refresh tokens to the client.

[wyssa14]

done