Oddbean new post about login | logout A quick write-up on how the OAuth-like flow I demoed yesterday works: https://github.com/kind-0/nsecbunkerd/blob/master/OAUTH-LIKE-FLOW.md This doc is likely not complete, but wanted to give a quick general overview of how it works.
Thanks for the write-up! Questions: - should username & email should be optional for create_account? Clients shouldn't be forced to implement nip05 name selection, plus some bunkers might assign nip05 names from partners/different domains etc - create_account is only for signup? it could in theory work in exactly the same way for login - user enters their nip05 on the client, client sends create_account but the bunker just checks if such nip05 exists and does the auth - Should bunker add itself to user's 31989 as handler for 24113? If it did, then if user changes their nip05 later, they could still login through a client with their new nip05 - client asks for nip05, checks .well-known of the new nip05 to see if it supports nip46 for this user, and if not - looks at 31989 to find the possible nip46 app for this user
* everything is optional (username, domain and email) * yeah, `create_account` should be mainly for signup, if a user is trying to create an account with a name that already exists I think it would be better for the user to see that the username is taken. Then they might think "oh, I already signed up, I need to log in instead". I think this is a more familiar flow. The client can easily check if that username already exists (nip-05), so they could show a "are you trying to login? click here" or something like that I think it should publish a 31989 but not for that reason. The NIP-05 is there just to find a pubkey, then the regular flow is what's really used, so the user changing their NIP-05 to something else is irrelevant, the `connect` request is sent to the user's pubkey, not to the bunker, so the 31989 is not really necessary to locate the bunker because the discovery of the bunker itself is not necessary.
> the `connect` request is sent to the user's pubkey But to which relay? 31989 to find the domain which leads to .well-known with your nip46/relay. Or?
oh yeah, ideally the new NIP-05 would copy the `nip46` nip05 entry
Doesn't look nice, third-party nip05 can change it at will and user has no control over it, 31989 is at least at user's control and is signed.
Do you envision passing app name and icon to auth_url? So that bunker could display them when asking for confirmation, and also in the list of connected apps? Or should those be part of create_account/connect requests?
No, as those are trivially forgeable so I think it’s better to not even try to show them and just rely on the URL if there is one. Perhaps we could use the domain of the URL and use a NIP-05 _@domain to resolve to a pubkey if the flow is web-triggered. There’s a callbackUrl that I forgot to document on the spec; I’ll write it up before I send the NIP PR
I agree those are forgeable, but having no app name/icon would hurt all normal users, while potential forgery would only hurt occasionally. I like your idea of using domain and nip05 of callbackUrl (I think you called it redirectUrl?). OAuth solves this by requiring app registration, but that not nostr way. Maybe we could require callbackUrl and redirect user to callbackUrl?token=accessToken which then has to be 'consumed' by the app with a new nip46 method to confirm it's identity? If callbackUrl doesn't belong to the attacker then they won't have the accessToken, doing this + your idea of using domain+nip05 could solve both naming and forgery. Anything wrong with this aside from complexity? As for the native apps without deep linking support, they could stick to using bunker: links which are more cumbersome for users but don't have these issues.