WeChat ID
aaronpk_tv
Monday, June 4, 2018
| bicycle |
54 min
|
|
8.4 miles
|
bicycle |
-
-
+1, the real solution to it would be to do what eg. the @indiewebcamp community has experimented with and brainstormed about: https://indieweb.org/GitHub Decentralized/indie social networks are for GitHub activities as much as they are for tweets, events etc
-
What I took from this article is that @SimoneGiertz is basically the modern day Rube Goldberg https://www.collectorsweekly.com/articles/rube-goldberg-got-tech-right/ -
What we really need is federated authentication, but that doesn't exist yet.
This sounds like a great use case for IndieAuth. w3.org/TR/indieauth
IndieAuth is an OAuth 2.0 extension, which avoids the centralized problems with existing OAuth solutions by using DNS for "registration" of client IDs and user IDs. Every user account is identified by a URL (for Gitea this could be your Gitea user page), and client IDs are also URLs (would be the Gitea instance home page in this case.)
To log in to your Gitea instance, I would enter my own Gitea profile URL. Your instance would then do discovery on my URL to find where to send me to authorize the login on my own OAuth server (my Gitea server), which would then send me back to your Gitea where it would be able to verify the authorization code against my Gitea instance.
I'd be happy to walk through this in more detail if you're interested!
-
If you're a good JS developer, speaker and writer, I'd love to work with you! We're hiring an awesome developer evangelist to help us with our JavaScript evangelism @oktadev. Hit me up if you're interested! <3 We have an awesome team: @mraible @leebrandt @aaronpk and me =D
-
It would be fantastic if Gitea were its own OAuth2 provider! In fact, IndieAuth is the perfect candidate for how to implement this.
IndieAuth is an OAuth 2.0 extension, which avoids the centralized problems with existing OAuth solutions by using DNS for "registration" of client IDs and user IDs. Every user account is identified by a URL (for Gitea this could be your Gitea user page), and client IDs are also URLs (would be the Gitea instance home page in this case.)
This would let people sign in to other Gitea instances without any sort of prior relationship or doing client registration and such. Happy to walk through this in more detail if you're interested!
-
Super excited about all the conferences I’m going to this summer!! @osbridge @IndieWebSummit @FluentConf @oscon.
-
Apple basically declaring war on adtech. Safari will halt tracking, Like buttons etc and ask permission; will thwart device fingerprinting (used by trackers to get round blocking of other tech) #WWDC18
-
Not quite, since OpenID Connect still requires registering clients to get client credentials to use with the flows. There is a dynamic client registration part of OpenID Connect, but this allows you to entirely bypass the need for registering clients separately since we just piggyback on the existing DNS for identifying clients.
-
＠c̲hris̲epps̲tein
http://chriseppstein.github.com/
•
Jun 4
john. why don't people microformat more? it's such a good thing.
We're microformatting a lot over in the #indieweb! https://indieweb.org/microformats (This tweet was literally brought to you by Microformats) -
at ImperialPortland, Oregon • Mon, June 4, 2018 4:22pmCocktails and code
-
I think IndieAuth makes a lot of sense as the way to implement a federated login protocol to provide a "simpler UX for OAuth2" login for Gitea as this issue is named.
It would also be possible to provide support for the "with GitHub" portion (as originally noted in the issue) without having to ask / wait for GitHub to implement IndieAuth, by adding https://indieweb.org/RelMeAuth support.
https://indielogin.com/ is an example of an open source service that supports both of those, IndieAuth as github.com/aaronpk suggested and RelMeAuth, and is in daily use by folks signing-into the IndieWeb.org site. -
It looks great! Congrats!
