Add support for FAPI for Singpass Login

[javierpng]

Problem

Add support for FAPI flow

Closes #799

Solution

The existing v2-OIDC flow for Singpass Login is deprecated and new RPs are advised to use the FAPI flow for integration with Singpass Login.

Features:

• Created a new /v3/fapi/par endpoint to create a sign request.
• /v3/fapi/auth will no longer take in the parameters that are currently present in the OIDC flow.
• v3/fapi/token will require a DPoP token

Improved Security

• A Pushed Authorization Request (PAR) is used to initialize a login session. Prevents Authorization request tampering via the GET query
• Use of proof-of-possession tokens (DPoP)
• PKCE

Configuration
process.env.FAPI_CLIENT_JWKS_ENDPOINT - for configuring the JWKS endpoint

Allowed Scopes
Currently, only the following are supported

• openid
• uinfin
• user.identity

Tests

As tests are not a norm in this repository, I tested manually with my test application.
A test endpoint is created for simulating the FAPI flow without a server setup.

Limitations

• The current PR only covers the Login flow, scopes are only limited to openid and user.identity
• Client_id, redirect_uri, can accept any values.
• Ephemeral keys, state and nonce are not checked for duplication.
• Since there is no Redis, I am relying on ExpiryMap for session management and using client_id as key instead of redirect_uri. If you are planning to run multiple login sessions at once, suggest to use client_id:<state> as the client_id

[LoneRifle]

lgtm otherwise

[LoneRifle]

nit - there should be naming consistency - if you have a fapi.service.js, you should have a fapi.controller.js too

[javierpng]

Resolved, thanks!

[LoneRifle]

MockPass auth endpoints would typically construct the issuer in a manner that trusts the requests, to ensure that developers can reconfigure mockpass as they wish without worrying

You may wish to look at the other endpoint implementations to see how this might be done.

[javierpng]

Resolved as well

[LoneRifle]

As discussed in the prior review. Please refactor as needed

[javierpng]

This is the default value if running locally.

I added a getFapiOpenIdConfiguration(req) that will be called by the service layer. This will determine the protocol and host and update the FapiConfiguration using the values in req during runtime.

e.g.

app.get(
    `${FapiUtils.FAPI_PATH}/.well-known/openid-configuration`,
    (req, res) => {
      return res.send(FapiUtils.getFapiOpenIdConfiguration(req))
    },
  )

When called, it will ensure that the endpoints are tagged to the developer's host

function getIssuerFromRequest(req) {
  return `${req.protocol}://${req.get('host')}${FAPI_PATH}`
}

function getFapiOpenIdConfiguration(req) {
  const issuer = getIssuerFromRequest(req)
  return {
    ...fapiOidcConfiguration,
    issuer,
    jwks_uri: `${issuer}/.well-known/keys`,
    pushed_authorization_request_endpoint: `${issuer}/par`,
    authorization_endpoint: `${issuer}/auth`,
    token_endpoint: `${issuer}/token`,
  }
} 

[LoneRifle]

Would it then be better to not actually have the default value at all, given that this would change at runtime? Having the hard-coded value and then discarding it at runtime strikes me as a code smell, and may catch out people who are relatively new to the codebase.

[javierpng]

Good point, I have removed the issuer from the code and refactored it. Thanks!

[LoneRifle]

lgtm