davidje13 / auth-backend Goto Github PK

e.g Okta:

• https://developer.okta.com/signup/
• https://developer.okta.com/docs/concepts/saml/
• https://developer.okta.com/docs/guides/build-sso-integration/integrate/

It should be possible to configure multiple SAML providers simultaneously

It may be desirable to provide a list of all retros within an organisation after logging in using saml

(migrated from davidje13/Refacto#18)

To allow easy integration with alternative authentication mechanisms, it should be possible to configure a trusted URL where it is assumed that if the user can reach the URL, they are trusted. This could be used with a proxy configured to require Mutual TLS for the configured path, for example.

const config = {
  trustedEndpoint: {
    path: 'my-trusted-path',
    userIdHeader: 'X-Ssl-Cert-Hash',
  },
};

Which could be combined with an nginx config:

ssl_verify_client on;
ssl_client_certificate /path/to/cert.crt;
ssl_verify_client optional;

location /ssoprefix/my-trusted-path {
  if ($ssl_client_verify != "SUCCESS") { return 403; }
  proxy_set_header X-Ssl-Cert-Hash $ssl_client_fingerprint;
}

It may be desirable to have other options than userIdHeader, such as userId for a fixed user ID for anybody able to reach the endpoint.

Things to consider:

• Care must be taken by the user to ensure the endpoint is fully protected. Might be worth allowing a configurable header-based password which can be set in the proxy as a bit of extra protection against accidental misconfigurations (wouldn't provide much protection though)
• Should it be possible to configure multiple trusted endpoints? What would that look like?
• How should this interact with the existing client-exposed authUrl property?

Alongside the google & github sign in currently offered.

• https://developer.apple.com/sign-in-with-apple/
• https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple
• https://developer.apple.com/documentation/signinwithapplerestapi

This appears to need a paid Apple Developer account, so probably won't be implemented.

(migrated from davidje13/Refacto#1)

Alongside the google & github sign in currently offered.

https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow

(migrated from davidje13/Refacto#2)

GitLab seems to have updated their supported methods and now returns:

The authorization server does not support this response type.

This is mostly a client concern, but some server-side support will be needed for generating challenges.

Need to understand the create-account / login flows better;

• https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
• https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer/create
• https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer/get
• https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer/preventSilentAccess
• https://developer.mozilla.org/en-US/docs/Web/API/AuthenticatorAttestationResponse

What is the challenge for in the create step? Seems to be focused on adding credentials to an existing account, but here we can consider it creating a new account with the new credentials. In this case, maybe the challenge is superfluous?

Server needs to be able to generate input params for the calls:

const options = await fetch('/auth/webauthn').then((r) => r.json());
let key = await navigator.credentials.get({ publicKey: { challenge: new UInt8Array(options.challenge) } });
if (!key) {
  key = await navigator.credentials.create(options.create);
  await fetch('/auth/webauthn', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ key: key.response.attestationObject }), // is clientDataJSON needed?
    // ...
  });
}
// we now (possibly) have a key which we can use to respond to a server challenge to exchange for a JWT

{
  "challenge": [0, 0, 0, 0, 0, ..., 0],
  "create": {
    "publicKey": {
      "rp": {},
      "user": {},
      "pubKeyCredParams": [],
    }
  }
}

The intended WebAuthn flow is still unclear; is the expected flow to create first (but with excludeCredentials somehow?) then always use the same get call with data and a challenge to perform the JWT exchange?