lepeuvedic
commented
6 months ago Excluded from the current perimeter until a back-end with adequate technical characteristics actually appears.
Closed lepeuvedic closed 5 months ago
lepeuvedic
commented
6 months ago Excluded from the current perimeter until a back-end with adequate technical characteristics actually appears.
Problem
The front-end expect the back-end to deliver data without authenticating. This is not a valid assumption because it's trivial to use the development tools in the browser to discover what are the API calls. Then anyone can use the API calls to milk our clients data without authenticating anywhere. There is no access control. The clients will not accept it.
How to Reproduce
Just run the software against the development backend and observe that it works. The development backend has no authentication mechanism.
Expected Behavior
The back-end uses AWS IAM Authorization, which means signed requests provided by the AWS-specific signing function are necessary. IAM selects a principal, an identity with which, it will perform operations on cloud objects (typically the REST API, but also possibly S3 and AWS KMS, AWS STS and other AWS APIs accessed directly).
The front end must use OIDC to authenticate to the back-end. Sending a first request for data will result in a redirect to a FusionAuth (or other) login page on https://auth.natixar.pro/login. When the user successfully authenticates, FusionAuth redirects the browser to the front-end, which recovers the authentication code, in the form of a JWT. The AWS STS service can be used to exchange this token against a set of usual temporary AWS credentials which define a principal, and an assumed AWS IAM Role (privileges).
The AWS function is
aws sts assume-role-with-web-identity. It takes as parameters an IAM role, the token and a duration. When the duration is half exhausted, the recovered refresh token should be used to extend the duration of the authorization.