[Ur] The right way to do federated login in 2015?

[1337 777]

Here is some working oauth source code which get the userinfo api of
the author, this is some copy-paste duplicate on the side of the
openid source code for easy comparison, no trimming out
https://github.com/1337777/oauth
http://hg.impredicative.com/openid

It is not technical but it is minimal and necessary and it takes
someone to take the time to type on the keyboard and resolve
ridiculuous bugs
... example: github require some user-agent header and this must be
done in curl with CURLOPT_USERAGENT not with CURLOPT_HTTPHEADER ..
github does not accept SSLv3 and this must be erased from the curl call
github gives the response of curl POST access_token in urlencoded    =
and &    form but the original OpenidFFi.direct was parsing the
response using    : and \newline
github maybe has some bug during the authorization code exchange
because this must be tried 2 times to get success access_token

...the oauth interface of google has the same form so this source code
shall be ok with google

kthxby now COQ

On Thu, Nov 19, 2015 at 4:17 PM, 1337 777 <1337777.net at gmail.com> wrote:
> After reviewing
> http://hg.impredicative.com/openid
>
> The only programmation thing which is extra beyond OAUTH is:
> * temporarily storing the connection ("endpoint") tools:
>     + dh secret exchange when not on httpS
>     + enciphering/deciphering the hmac key using the dh secret
>     + signing/verifying the connection data using this hmac key
> * permanentlly storing the pairing of "user" profile with "identifier"
>
> Therefore maybe some boring 3-hours trimming out of the texts of the
> connection tools and the user-identifier pairing, without touching
> anything else, shall give OAUTH... so what sense exactly is "some
> oauth library" ?
>
> hmmmm.. I have this OAUTH schema in mind for
> https://developer.github.com/v3/oauth/
>
> authorize
>     ->GET redirect_uri stIdx, state, (scope)
> ~~Basis.redirect()/FFi.indirect()
> redir_uri stIdx
>     <-BACK code/identifier, state, [cookie]
>     ->RPOST code/identifier, client_secret        ~~FFi.discovery()/FFi.direct()
>     <-HTML token/endpoint, (token_scope, token_type)
> apiform
>     ->POST api_uri, token/endpoint
>     <-HTML user
>
> seq0: {stateIndex}
> tab1: {stateIndex, state, option code/identifier, code_scope,
> expirity, option (token/endpoint * token_scope * token_type)}
> cookie: {stateIndex, state}
>
> ...
>
> (ok ok ... I was putting on hold my coq proof of the biassociative
> coherence, now I will write it before December 4 and publish somewhere
> else just to be annoying)
>
> On Thu, Oct 22, 2015 at 10:37 PM, 1337 777 <1337777.net at gmail.com> wrote:
>>>
>>> I'm motivated enough about at least the OAuth part, as I want to use
>>> it for a web app, aimed at developers, to do login with GitHub
>>> credentials.  So, I expect that bit would get done by early 2016, even
>>> if no one else volunteers.
>>
>> how is this different than doing the crypto-signing/verifying
>> mathematics not in the browser but behind some web interface ?
>>
>> Ultimately this is the genre of programming activity that I may do in
>> the near future for some concurrent web app, therefore "I"😏 may as
>> well start now until someone else is quicker ? (part-timing from
>> readying for the univalent-foundations workshop this may 16-20 at the
>> fields institute)