contra re weblogin

gistfile1.txt

2:39 PM <•jden> contrahax: so critique weblogin
2:39 PM <•jden> tear it to shreds
2:39 PM <•jden> what am i getting wrong
2:40 PM <•contrahax> jden link again?
2:40 PM <•jden> https://github.com/jden/web-login
2:40 PM <•jden> basically the only thing your app gets back is a guid
2:40 PM <•jden> tell me why authentication needs more than that
2:40 PM <•contrahax> jden why a promise tho
2:40 PM <•jden> because web platform
2:40 PM <•contrahax> i wont even argue about that
2:40 PM <•jden> but that's not the important part
2:40 PM <•contrahax> not worthwhile
2:41 PM <•jden> promise callback, whisper in ear
2:41 PM <•jden> w/e
2:41 PM <•jden> new async abstraction: george michael's careless whisper
2:41 PM <•contrahax> so what is this accomplishing though
2:41 PM <•contrahax> what type of website would be using this login
2:41 PM <•jden> contrahax: browser-provided identity, abstracting the identity provider from the application
2:41 PM <•jden> anything that cares about you having an identity
2:41 PM <•jden> replace user/pass prompts with a "login" button
2:42 PM <•contrahax> jden does the UUID have any link to the provider?
2:42 PM <•jden> no, it's like a hash or something
2:42 PM <•contrahax> jden how do i use the uuid to get more info
2:42 PM <•jden> you dont
2:42 PM <•jden> it's completely separate, but it is unique
2:42 PM <•contrahax> like the persons name, email, birthday, avatar, etc.
2:42 PM <•jden> to the user
2:42 PM <•jden> you dont
2:42 PM <•jden> unless they give it to
2:42 PM <•jden> you
2:43 PM <•contrahax> oh so this is like persona-esque
2:43 PM <•jden> yeah, but even more bare bones
2:43 PM <•contrahax> browser identities gotcha
2:43 PM <•contrahax> not like chromes identity stuff
2:43 PM <•jden> persona was too complicated because you needed 3rd party verification servers
2:43 PM <•contrahax> which is really login with gmail
2:43 PM <•jden> right
2:43 PM <•jden> so the browser could use oauth or persona or w/e behiind the sceness
2:43 PM <•contrahax> how do you validate that the token is correct on the server?
2:43 PM <•jden> fuck i cant type today
2:44 PM <•jden> contrahax: just if its the same as when you first registered
2:44 PM <•jden> it's a token
2:44 PM <•contrahax> jden but how do you check if its a real token
2:44 PM <•jden> so it's both identity and proof of that identity
2:44 PM <•jden> beccause its long
2:44 PM <•contrahax> i can generate a random guid and POST it at your service
2:44 PM <•contrahax> to create fake accs
2:44 PM <•jden> yeah
2:44 PM <•jden> and if you do it again, then its the same acct
2:44 PM <•jden> or a new acct
2:44 PM <•contrahax> jden yeah i just make a new guid
2:44 PM <•jden> it's up to the app to handle the registration process
2:45 PM <•jden> which would probably then ask you for an email or w/e
2:45 PM <•jden> to fill out additional details
2:45 PM <•jden> maybe associate a phone or w/e, depending on the level of security required
2:45 PM <•jden> the idea is that that's all application level concerns
2:45 PM <•jden> same with any sort of authorization concerns
2:45 PM <•jden> this is as pared down as possible, just to say "hey, it''s me"
2:46 PM <•contrahax> if the id from the API cant be verified though is it worth using?
2:46 PM <•contrahax> if you have to implement your own verification system anyways
2:46 PM <•jden> well, consider: it's the same way that APIs do it
2:47 PM <•jden> the idea behind the token is that it's unique and hard to forge
2:47 PM <•jden> whether it means anything or is associated with a user account or permissions or whatever is up to the app
2:48 PM <•jden> server side
2:50 PM <•contrahax> jden but its not hard to forge because i can generate a guid
2:50 PM <•contrahax> skjdhfs-sdfsdfs-sdfsdfsd-sdfsdf
2:50 PM <•jden> yeah, but not the *same* guid
2:50 PM <•jden> also, get your base36 encoding away from me
2:50 PM <•jden> :p
2:50 PM <•contrahax> jden this system prevents people from stealing accounts but doesnt prevent abuse of making fake accounts
2:51 PM <•contrahax> i think thats something persona is really useful for
2:51 PM <•jden> that's up to the app though
2:51 PM <•contrahax> this eliminates the username and password portion
2:51 PM <•contrahax> which i think is cool
2:51 PM <•jden> what if you just need to be able to same some sort of preferences or whatever
2:51 PM <•jden> like what duckduckgo does
2:51 PM <•contrahax> im just left wanting more though
2:51 PM <•jden> what other things
2:51 PM <•jden> this feedback helps btw
2:51 PM <•contrahax> so how do you envision browser integration working
2:51 PM <•jden> i'm mocking that up right now
2:52 PM <•jden> so navigator.login() would open like an ID picker with the actual login stuff
2:52 PM <•contrahax> jden would i log into chrome with gmail, firefox with persona
2:52 PM <•jden> which the browser could cache or w/e
2:52 PM <•contrahax> and then every browser i want my accs on i just log in using w/e other login the browser uses
2:52 PM <•jden> could either be that or there could be some other sort of generic identity provider registration scheme, like web intents or something
2:52 PM <•jden> contrahax: that's the thing, you'd need to use the same IDP with each browser
2:52 PM <•jden> or associate multiple IDPs with that acct
2:53 PM <•jden> or w/e
2:53 PM <•jden> because the guid generation process would have to be deterministic
2:53 PM <•jden> but opaque to the application
2:53 PM <•contrahax> jden so the guid is tied to the domain right?
2:54 PM <•jden> yeah, it'd be some vector of the requesting domain and whatever is returned by the idp
2:54 PM <•contrahax> jden otherwise cant i, a horrible site owner, take someones guid that was on my service and impersonate them across the web
2:54 PM <•jden> right, it'd be unique by domain
2:55 PM <•contrahax> navigator.login = function(cb) {magic(hash, origin)
2:55 PM <•jden> so, one of the things i'm trying to work out is revocation & how that would work
2:55 PM <•jden> contrahax: in pseudocode, exactly
2:55 PM <•jden> where magic is a hash function
2:55 PM <•jden> and `hash` is given by the IDP
2:55 PM <•jden> and possibly cached by the user agent
2:56 PM <•jden> eg a "remember my logged in identity"
2:57 PM <•contrahax> so its like https://gist.github.com/contra/0679ef971f2be3365fa6
closecontra — 6 Apr 2014
1 2 3 4 5 6   

navigator.login = function(cb) {
browser.getUniqueId(function(id){
if (!id) return cb('No go!');
cb(null, magicHash(id, location.origin));
});
};

view raw login.js hosted with ❤ by GitHub
2:58 PM <•contrahax> revoking will be difficult
3:00 PM <•jden> yeah, something like that gist
3:00 PM <•contrahax> jden and what make it worthwhile is that browser.getUniqueId is not accessible to anything but this special api
3:00 PM <•contrahax> what are your thoughts on revocation?
3:00 PM <•jden> well, there is no getUniqueId
3:01 PM <•jden> getUniqueId would be, eg, a persona token, or an oauth token, or whatever
3:01 PM <•jden> from the underlying IDP
3:01 PM <•contrahax> jden the browser provides a unique id which is hashed with the origin, right
3:01 PM <•jden> it's identifying the user, not the browser
3:01 PM <•jden> otherwise you could use a mac address or a machine guid or w/e
3:01 PM <•jden> i mean
3:01 PM <•jden> if you want to write your own crazy user agent and do something like that you could
3:01 PM <•jden> i guess
3:02 PM <•jden> my thoughts on revocation are not really articulate. it would be like revoking an oauth token
3:02 PM <•jden> meaning that the underlying app just refuses to accept the generated weblogin token
3:02 PM <•jden> the user would have to have some other sort of thing associated with their account then
3:02 PM <•jden> like an account recovery flow
3:02 PM <•jden> via email or text or w/e
3:04 PM <•jden> also, i made #weblogin