Refactor not to require PHP session about webauthn-framework

[Spomky]

Hi @srigi,

I am aware of that and is will fixed soon. Have a look at the #47. I pushed the code few hours ago and this will be available in v1.2.

The demo will be updated as well with a react frontend instead a plain old form + twig templates.

[moderndeveloperllc]

@srigi FWIW, you can implement without Symfony if you want. I'm using this library with a Zend Expressive middleware pipeline.

[Spomky]

I answered too quickly . Here is a more precise answer.
This authentication mechanism needs at least 2 requests:

• the first one to get a PublicKeyCredentialRequestOptions object
• the second one to send the assertion computed by the authenticator using the PublicKeyCredentialRequestOptions object

The firewall have to keep track of the PublicKeyCredentialRequestOptions object sent to the authenticator. It is used by the validator to verify the assertion received from the client (especially to prevent challenge forgery attacks). Thus this authentication mechanism cannot be stateless.

I use PHP sessions as it is a convenient and secured way to manage that.
Once your user is logged in, nothing prevent you from issuing access tokens or whatever you need the consume your REST api in a stateless manner.
The react app I am preparing for the demo doesn't care of the session cookie received by the Symfony application. In the demo, the only requirement during the login process is to set credentials to "same-site" as the cookies are secure, httponly and samesite is strict.

As suggested by @moderndeveloperllc, other alternatives exist (e.g. routes with an ID of the PublicKeyCredentialRequestOptions).
Anyway, the idea to implement a custom storage is a nice idea. This could be achieved using a new firewall option and a default storage based on cookies.

[Spomky]

Hi @srigi,

I merged the Json Firewall to the v1.2 branch few days ago.
This new firewall will ease the use of script apps (e.g. Vue or React apps).

I will add 2 new options to this firewall within the next days: success_handler and failure_handler.
These handlers will allow you to customize the responses returned by the firewall. For example, you will be able to generate an access token (e.g. using LexikJWTAuthenticationBundle) and return it the way you want (in the response body or through the query/fragment of a redirect uri).

In any cases, the PHP session will still be used by this firewall as explained earlier. However, with these handlers you will access the request and thus the session that could be deleted if needed.

[Spomky]

@srigi please have a look at #51. This PR will help you to fix that issue.

[Spomky]

Closing as merged in v1.2.

[srigi]

@Spomky sorry for not responding. I was dealing with other projects.
PR #51 looks great, thank you very much.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.