-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add JWT validation auth middleware #57
Conversation
Also ran `go mod tidy`.
Improves code readability and prevents bugs.
User validation still remains as a TODO.
Also made a comment clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some areas for improvement such as the elimination of the global variables within the auth
package, but this will be done in a future refactor PR instead.
@YaleChen299 due to the way the service uses a singular JWKS source, at the moment. This service can only support a one-to-many relationship between the main backend and the stories backend. However, this implementation should be flexible enough to support a many-to-many relationship to fully support multitenancy as defined in #15, via a relatively simple refactor to use maps instead of strings pointing to multiple JWKS sources. |
This is to say to allow tokens issued by other trusted backends as well right? In this case, do we need add the respected source manually? |
Part of #16.
Adds a middleware that ensures all requests to protected routes must be authenticated (unless in development mode). Authentication is based on RS256 public key verification, with the JWKS source coming from the main backend (currently defined using an environment variable, to be refactored in a future PR).
Note that as our backend does not have the necessary DB schema/structure to support full user verification, as of now, the middleware only validates that the user has been authenticated with the main backend before granting requests (it has no notion of which user is currently accessing the service in order to support the features/roles defined in #15 and #18).