Or, would it make sense to just re-authenticate every time you wanted to log in, without identifying the client? Pablo proposed this and I don't see any need for a client to self-identify or maintain a persistent session with the authentication provider, other than a bunker key.
nostr:nprofile1qqsrxra3gv0lnkxz2pcxh0xuq9k4f9dr7azwq3aypqtnay4w0mjzmtqpzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcprpmhxue69uhhyetvv9ujucm4wfex2mn59en8j6f0qyghwumn8ghj7mn0wd68ytnhd9hx2tce33z4j I was just talking to nostr:nprofile1qqs04xzt6ldm9qhs0ctw0t58kf4z57umjzmjg6jywu0seadwtqqc75spzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszyrhwden5te0wdhkcmmrduhxump0c6w75y about the OAuth stuff. You had mentioned a vulnerability where an impostor client could hijack another client's session by authenticating with the same client id. I looked briefly at OpenID Connect's dynamic discovery mechanism, and it looks like you get a shared secret at registration. We have keys though, do you think it would make sense to have a client sign an authentication request using the same key they used to publish a NIP 89 app listing?
Discussion
No replies yet.