Currently, the protected-user-use-case just returns the value passed in the body of the corresponding request, if the user is authenticated via a JWT bearer header. This use-case should be refactored to handle step 4/5 in the login flow.
That is, if a global session exists for a user upon querying this use-case, the use-case should produce the same output as the login and creation endpoints: a redirect to the redirect_url of the service provider with the necessary short-lived authorization code (without the need to create an account or login beforehand). Otherwise, the use-case should return a redirect to the login/creation microservice UI page where step 5 in the login flow is initiated. The authorization code can be generated and saved as done with the AuthCode entity in the login/creation ticket (maybe look at how to re-use that code here to prevent too much copying over)
Other details:
This use-case should now receive the query parameters specified here.
Note that before any other processing, the client_id param should be verified by checking if it exists in the AuthSecret collection. If it does not, return a 403 Forbidden HTTP status.
Currently, the protected-user-use-case just returns the value passed in the body of the corresponding request, if the user is authenticated via a JWT bearer header. This use-case should be refactored to handle step 4/5 in the login flow.
That is, if a global session exists for a user upon querying this use-case, the use-case should produce the same output as the login and creation endpoints: a redirect to the
redirect_urlof the service provider with the necessary short-lived authorization code (without the need to create an account or login beforehand). Otherwise, the use-case should return a redirect to the login/creation microservice UI page where step 5 in the login flow is initiated. The authorization code can be generated and saved as done with theAuthCodeentity in the login/creation ticket (maybe look at how to re-use that code here to prevent too much copying over)Other details:
This use-case should now receive the query parameters specified here.
Note that before any other processing, the
client_idparam should be verified by checking if it exists in theAuthSecretcollection. If it does not, return a 403 Forbidden HTTP status.