3 ms·
There is the possibility of using a capability URL: https://www.w3.org/TR/capability-urls/ https://www.w3.org/TR/capability-urls/ Problem is of course that UR
by raxxorraxor 3y ago
There is the possibility of using a capability URL:
https://www.w3.org/TR/capability-urls/ https://www.w3.org/TR/capability-urls/
Problem is of course that URLs are not treated as a secret, but with widespread TLS I still consider it safe. I do employ some services that make use of it and access logs confirm that it is still a viable solution.
Of course it depends on how well users treat this "secret" and the URL should only be valid for a limited time (That can be much longer than the usual PW reset though, depending on your use case).
- rrr_oh_man 3y agoGreat! I tried something similar to this in the early stages without having a name for that concept or an idea of how it should be implemented. You now enabled me to research different approaches. Thanks!
- raxxorraxor 3y agoI think it is one of the very few possibilities to provide privileged info without the need to create an account. Handy for a lot of applications, since users might skip access if they have to register for yet another service. The term "capability URL" isn't too widely known, but the mechanism is very widely spread (almost all password resets for example) and you do find it in several technical documents. Perhaps you could also combine it by then setting a cookie and invalidating the URL to allow for extended access. Just as URLs, secure HTTP-only cookies still do have attack surfaces. But for many applications it does provide "enough" security and storing access tokens client side is common practice. I believe cookies are still the safest option for this compared to local browser or session storage. But I am not sure.