feat: Authorization token storage

[RodolfoSilva]

Description

We need a way to persist and destroy the passkey on the device to allow apps that have authentication to be able to persist the passkey locally and avoid the user having to provide credentials again.
Perhaps a simple encrypted key-value storage will solve this use case.

And also some way to always send this data in the request to the server, through the header perhaps.

Requirements

• Store the key value provided by the server
• Destroy the value using the key provided by the server
• Send the data to the server in every request in the header

Additional Context

This will unlock advanced features when the app needs to keep some data locally to be used in future accesses.

Maybe it's just a feature to store a bearer token locally and send it every time the app requests something from the server.

[i-asimkhan]

Hey, @RodolfoSilva It's a great idea we have done an investigation and here is a detailed analysis of this issue.

In the context of Mirai (server-driven UI framework for Flutter), there are two main challenges, one is to authorize the right client to retrieve UI resources and the other is to pursue the right resource of user-specific data inside the user interfaces.

For instance, let's skip authorizing the accessibility of Mirai interface templates, then here is the list of challenges we have.

• The main challenge that remains is logging-in users with custom server requests and storing the authorization to retrieve user-specific details and represent them inside the visible template.
• Furthermore, user actions will post details to their own custom servers using the Mirai template which too requires authorization.
• Finally, when the user tends to stop their user activity with their custom server, Mirai needs to find a way to log out user from the authorized part and destroy the authorization information.

Now let’s discuss what are the possible ways in which we can achieve this functionality in Mirai.

• We can use secure storage inside the framework key-value passed by the server, in this way, we can build a mechanism to store values securely inside the framework regardless of what value it is and when it is going to get destroyed. The framework will only play a part in doing the business, the framework-enabled flutter app will only decide when and for what reason to do this. Authorization in this case will be returned back to the app from the framework and the app will either store it through the framework’s secure channel or internally.
• The next pattern we are discussing does not involve the Mirai framework to store Authorization, instead, the simpler way discussed above returns data back to the app for network requests.
• Introducing a widget in Mirai that can authenticate users with their login credentials and upon successful retrieval of authorization details, beneath this widget every widget would remain authenticated unless the user tends to stop the retrieval or close the app.

After this detailed analysis, we have come up with this solution that we can use secure-storage of the key-values which is completely independent of the fact that we are going to use it for storing and retrieving authorization but it will provide Mirai with an added functionality of secure storage. What are your thoughts on this?

[RodolfoSilva]

I think if we add the ability to add new custom actions like we do with widgets, it gives more power to the user to decide how they want to use their local storage or something else. Mirai now supports receiving a Dio instance, this allows the user to implement their own authorization strategy and even invalidate the authorization.

But I think the main purpose of making this feature possible is to provide a way to register new custom actions like we did for widgets.