Post AkLHzuRxWBFB22EpQu by ilovecomputers@xoxo.zone
(DIR) More posts by ilovecomputers@xoxo.zone
(DIR) Post #AkLHzuRxWBFB22EpQu by ilovecomputers@xoxo.zone
2024-07-27T02:49:57Z
0 likes, 0 repeats
Good news everyone! Mastodon's OAuth should soon support PKCE. This will allow browser-based apps to authenticate with an instance without storing the secret in local storage. This will also mean I'll have to review @aaronpk's guide https://aaronparecki.com/oauth-2-simplified/#single-page-appsMy request to support that extension was closed today https://github.com/mastodon/mastodon/issues/21913Thank you @thisismissem for fixing this! :rocket_turtle:
(DIR) Post #AkLWQrc5ZTkdPYiuFU by thisismissem@hachyderm.io
2024-07-27T05:31:44Z
0 likes, 0 repeats
@ilovecomputers no, this isn't correct. PKCE only protects the Authorization Code.You're thinking of Public vs Confidential clients, which we have NOT implemented yet.The reason we've not implemented those is because of issues around token expiration and refresh tokens. Support for public clients, refresh tokens, and more is planned, but won't be in 4.3We took the decision that support PKCE for all client types improved security in general.
(DIR) Post #AkLYZGDSBOgnwLKe2q by thisismissem@hachyderm.io
2024-07-27T05:36:06Z
0 likes, 0 repeats
@ilovecomputers currently in 4.3, all clients will remain as confidential clients, and be issued a client_secret.We know this isn't up to Security Best Current Practices, but evolving this code without breaking existing clients is rather difficult.This work is also funded by my supporters: https://support.thisismissem.social
(DIR) Post #AkLYZHEYOnAD62r2Om by ilovecomputers@xoxo.zone
2024-07-27T05:55:40Z
0 likes, 0 repeats
@thisismissem thanks for the clarification! Edited the original post to remove my incorrect statement 😅
(DIR) Post #AkLZNc0HS3BpzZBCxE by thisismissem@hachyderm.io
2024-07-27T06:04:46Z
0 likes, 0 repeats
@ilovecomputers yeah, PKCE is now recommended for all client types, due to Authorization Code Injection Attacks, see: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topicsSo whilst we couldn't add Public Clients with refresh tokens yet, we thought at least protecting the code parameter from theft was a good idea.Goal is to support Public Clients and be inline with Security Best Current Practices, but this'll likely happen over several releases.Like, here's all the OAuth changes in just 4.3: https://github.com/mastodon/documentation/pull/1445
(DIR) Post #AkLc1JTxvqIG2c7il6 by thisismissem@hachyderm.io
2024-07-27T06:34:21Z
0 likes, 0 repeats
@ilovecomputers you may also be really interested in the IETF Internet Draft I'm coauthoring with Aaron Parecki that aims to solve the issues with Dynamic Client Registration in federated & decentralized services.https://drafts.aaronpk.com/draft-parecki-oauth-client-id-metadata-document/draft-parecki-oauth-client-id-metadata-document.htmlI think this will supersede POST /api/v1/apps (Mastodon's form of DCR) for most apps.Video introducing it at IETF 120 here: https://youtu.be/s0u-ORqr8to?t=4958
(DIR) Post #AkLfRYxNJxfLQS5W1g by ilovecomputers@xoxo.zone
2024-07-27T07:12:43Z
0 likes, 0 repeats
@thisismissem reviewing how @phanpy does it and learned they store the secret temporarily in session storage https://github.com/cheeaun/phanpy/blob/4c0bc62ad016eb36e7e1bd909fc21728bee1f0c4/src/app.jsx#L317but store the access token more permanently in local storage.
(DIR) Post #AkLjSBR6eeB2aIXuMq by thisismissem@hachyderm.io
2024-07-27T07:57:37Z
0 likes, 0 repeats
@ilovecomputers @phanpy yeah, like I mentioned OAuth Client ID Metadata Documents is going to change this so you don't even need to worry about getting a client_id and client_secret — client_id will be a URL to a json document containing your client metadata & the Mastodon server (AS) will automatically create the application if it needs to.