You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 theAuthCode
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 theAuthSecret
collection. If it does not, return a 403 Forbidden HTTP status.The text was updated successfully, but these errors were encountered: