Skip to content

Refactor protected-user-use-case to handle global session check #10

@ShreyasPrasad

Description

@ShreyasPrasad

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions