Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication from mutliple JWT issuers #696

Closed
MeStrak opened this issue Feb 9, 2022 · 1 comment
Closed

Authentication from mutliple JWT issuers #696

MeStrak opened this issue Feb 9, 2022 · 1 comment
Assignees

Comments

@MeStrak
Copy link
Contributor

MeStrak commented Feb 9, 2022

Is your feature request related to a problem? Please describe.

As Whispr is designed to be a hub that multiple clients to connect to, it would be great to offer authentication which allows direct passthrough and validation of JWTs for those clients to avoid the need for an additional authentication against whispr.

Describe the solution you'd like

  • Clients within a trusted environment should be able to log in with their existing JWTs.
  • Security config should be parameterised and not hard coded.
  • All queries/mutations/endpoints should be secured (possibly with a global guard).

Describe alternatives you've considered

Option x

  • Use standard passport-jwt which allows for only a single JWT issuer or secret.
  • This option is not selected because it would either force additional authentication to whispr, or limit each whispr instance to only one client.

Option y

  • Use an extended version of passport-jwt implemented in @MeStrak/passport-multi-jwt which allows configuration using an array of passport-jwt configurations.
  • Manage configuration through an env var, so that no code modification is required to configure an additional JWT issuer or secret.
  • Use of guards to be reviewed - a global guard might be possible, but we should take into account future requirements of restrictions at Application ID level (see additional context)

Additional context

This feature covers authentication only, not authorisation. As a next step we should look into authorisation at application ID level to protect the data further.

@MeStrak
Copy link
Contributor Author

MeStrak commented Mar 3, 2022

Implemented with #694

@MeStrak MeStrak closed this as completed Mar 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant