Venkatesan I suggest you do more homework here.

1. 'Session' operates off cookies. If you don't like cookies for some reason, you don't like session. Worse, the server side of sessions is inherently unscalable and do not operate perfectly with real load balancing. 
2. 'Local storage' is no more or less secure than a cookie. If you think cookies are unsecured, than local storage has the exact same vulnerability profile.  Worse, you'll need to read from the local storage on each and every request and send the security data to the server for request authentication. A huge process that is not worth building -  especially since this is essentially what a cookie does. 

Further to note:

1. The "cookieless" option, available in some security apparatus, moves the same data you find in a cookie through the URL query string instead of the request header (where cookies are located). They can be equally manipulated and are as secured or unsecured as the other. You're moving peas around on the plate.
2. Most security frameworks today use secure cookies, from SAML to OpenID (and OAuth) tokens.  These are the standard mechanisms found in stacks from Azure AD to Okta. 

Last, if you ensure secure cookies are used (SSL + samesite + httponly etc), then they are as secure as it gets. You need to ensure your hosting application operates with these tight settings so all its cookies (including the one required by Pyramid for embedding) are secured. 

There are no plans to support session cookies (same thing essentially) or anything else. In the current realm and iteration of HTTP and modern HTML5 browser mechanics, cookies remain the best option for security operations between the client and server.

All SSO models require some type of authentication token, which is usually stored/transported in a cookie. If you have specific examples or documentation for alternatives please add it to this thread.