We need to find a good place for the static random() function (which was previously an instance method on BaseRequest, and is now a static method in IDToken and AccessToken).

This issue is a placeholder for that design discussion. (from PR #28)

Add support for optional OIDC spec section 6.1. Passing a Request Object by Value, which discusses passing in an Authorization Request as a JWT in a request parameter.

If an RP makes an auth request, and its redirect_uri param contains a hash fragment, the fragment gets lost (in implicit flow) since it gets overwritten by #id_token=...&state=... response params.

Two things need to happen:

One: preserve the original hash fragment of the redirect_uri, and add the response parameters in addition to it.

So, if the authentication request gets made with redirect_uri=https://example.com/resource#someHashFragment, the implicit flow authentication response needs to redirect to:
https://example.com/resource#someHashFragment&id_token=...&state=...&access_token=....

Note that whatever auth client is parsing the response needs to be aware of this and preserve the hash fragment while parsing (and clearing out) the response params.

Two: Since the redirect_uri of an auth request needs to be compared to the pre-registered redirect_uris array, let's make sure that the comparison is independent of hash fragments.
That is, if the RP registers redirect_uris=['https://example.com/resource'] during its dynamic registration, a subsequent redirect_uri during an auth request should be able to pass in redirect_uri=https://example.com/resource#hashFragment and have that be valid.

(Affects downstream issue nodeSolidServer/node-solid-server#571)

• Discuss/revisit whether OIDC Core section 3.1.2.6. Authentication Error Response and the OAuth 2 Section 4.1.2 Error Response (to which the OIDC spec links) require that all error responses be handled as 302 Redirects (which includes 401s, 403s, etc).
• Add the state parameters to other error handlers in BaseRequest, aside from redirect() (also section 3.1.2.6).
• See also issue #19.

Need to add the error detail parameter to BaseRequest.forbidden().

Client code (for example, AuthenticationRequest.js#L62) is passing in error details, but the function doesn't do anything with them (see BaseRequest.js#L129)

When the client ID is unknown, the result is a 401 Unauthorized without any explanation. I propose to make this a 400 instead, with an appropriate error message.

This would help us find bugs such as nodeSolidServer/node-solid-server#592 faster in the future.

Current behavior - returning badRequest(whatever). For example, in TokenRequest.verifyAuthorizationCode():

          return request.badRequest({
            error: 'invalid_grant',
            error_description: 'Authorization code expired'
          })

The problem with this approach is that it doesn't break out of the promise chain, and continues onto grant(), and fails on the first line of that function:

  grant (request) {
    let {grantType} = request

(Since what's being passed into grant() is not a token request, but a badRequest() promise.

Anyways, this error handling flow needs to be refactored, and needs to rely on throw, to break out of the promise chain.

Missing a byte length argument in AccessToken.js#L30

For the purposes of functional/end-to-end testing of REST endpoints (for example, using the supertest library for testing Express.js apps), the test setup will frequently require authentication via Access Tokens.

Performing the usual dynamic registration and authentication dance for each test gets to be prohibitive. Even doing it just once before the test suite is difficult, given the current state of Express.js testing tools, but even when successful, violates best practices of not relying on global state between tests.

To that end, it would be extremely helpful to have a provider.issueAccessToken(options) convenience method. (Especially useful for testing decentralized oauth Peer nodes, where the testing framework could potentially have easy access to an OP (Provider) instance.)

The options passed into it would include things like client_id, sub, scope and, optionally expiration.

We forgot to include a return statement on line TokenRequest.js#L388. Currently the function returns null instead of a promise (and any errors in it are silent/unhandled).

Implement /logout api endpoint / handler (removes the appropriate access & refresh tokens from the store, etc).

With injectable behavior for host to be able to put together a user info object.

Here's the current AuthenticationRequest workflow:

  static handle (req, res, provider) {
    let {host} = provider
    let request = new AuthenticationRequest(req, res, provider)

    Promise
      .resolve(request)
      .then(request.validate)
      .then(host.authenticate)
      .then(host.obtainConsent)
      .then(request.authorize)
      .catch(request.internalServerError)
  }

The problem I'm running up against is that - the last step, request.authorize, always ends up writing a redirect to the response object. Which causes an error if either the host.authenticate or the host.obtainConsent steps write anything to the response before that.
Meaning, if either the authenticate or obtainConsent steps respond with anything to the browser (which they need to), the request.authorize call results in a Can't set headers after they are sent. error.

Need to rethink how this workflow goes (at least check, in request.authorize, to see if the response has been written to, or something like that.)

Currently, the various OIDC-related API endpoints are hardcoded in the Provider's constructor:

    data['authorization_endpoint'] = `${issuer}/authorize`
    data['token_endpoint'] = `${issuer}/token`
    data['userinfo_endpoint'] = `${issuer}/userinfo`
    data['jwks_uri'] = `${issuer}/jwks`
    data['registration_endpoint'] = `${issuer}/register`
    data['check_session_iframe'] = `${issuer}/session`
    data['end_session_endpoint'] = `${issuer}/logout`

(This also affects how they're advertised in .well-known/openid-configuration).

It would be preferable to allow a consumer app to specify which URI path to mount these endpoints on. Sort of like:

let provider = new Provider({
  issuer: 'https://example.com',
  mount: '/oidc/'
})
// -> which would lead to:
// https://example.com/oidc/authorize
// https://example.com/oidc/token
// https://example.com/oidc/userinfo
// etc

Note: This is only a refactoring of the provider's discover() functionality, not anything to do with OP express routes.

To maintain a standard style across our repositories and to aid new contributors, I propose that we add EditorConfig files to our repositories and make a note of it in our READMEs.

Most editors (vim, Sublime, Atom, VSCode, etc.) have plugins for EditorConfig making it relatively easy to automate tab indentation size, UNIX line-endings and ensure that files end with a new line.

Please see the @trust/model README and .editorconfig file for the proposed configuration.

See TODO in AuthenticationRequest/supportedResponseType()

Currently, I'm calling provider.initializeKeyChain() on service startup each time.
Would like to have the option of serializing the provider (and keychain) to json, and loading from disk.