We are able to @Inject the Identity bean only during handshake and perform any authentication there. After that, the protocol is upgraded and both request and session scope are not available when interacting with the server endpoint. That said, you can easily authenticate the user by using the Http Security Api during handshake. Also, you can also share information using the EndpointConfig.getUserProperties, where you can put everything you need during message exchange. Of course, better would be inject the Identity bean ....

I totally agree with you regarding the session scope, makes more sense. Specially because WebSockets already have the concept of a session, just like you said. We can definitely support a session scope, but I think that is something that should be provided by WebSockets implementations.

Also, even if session scope is supported (eg.: if we create one by ourselves), we still have issues with beans annotated with @RequestScoped such as DefaultLoginCredentials, IdentityManager, RelationshipManager and so forth. So we also need to an active request scope. Or maybe review the scope of those beans and make them @Dependent or whatever. That would bring some API changes (eg.: the DefaultLoginCredentials could not be injected anymore, but passed as an argument to Identity.login, etc) that I'm not sure is worth just to cover this particular use case.