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

[Adam Chlipala]

Thanks for the prototype code.  The OpenID framework is overkill for 
authentication that commits to trusting one particular counterparty, so 
I'd rather see a simpler implementation from scratch.  I'm not sure it's 
worth implementing anything beyond the latest version of the OAuth protocol.

On 11/21/2015 06:17 AM, 1337 777 wrote:
> 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)
>