For user accounts that have enabled multifactor authentication, how do you handle self-service password resets? On online platforms, it is usually possible to reset the password via email. I think that is fine for accounts that don't use multifactor authentication. But what if a user logs in with their phone number (They have no email, just the phone) and use text message as their second factor? Sending a password reset code via text message would be a bit stupid. This would mean that the user doesn't really have two-factor authentication if you can reset the first-factor with the second-factor.
I do currently not allow self-service password resets if a user has multifactor enabled. They are required to get in contact with customer support in that case. For our use-case this is ok, but it's obviously not very user-friendly. However, I don't really see a solution in the case where the phone number is the primary identifier and second-factor. I am interested in some thoughts on the topic.
Saw a demo of the #openid interop #test suite this week at internet #identity workshop #iiw. Very impressive! We need that kind of thing for the #fediverse.
🌟 This is the official Mastodon account for LemonLDAP::NG, a Web Single Sign On free software compatible with many open standards like CAS, SAML and OpenID Connect.
ℹ️ We will publish here information about releases and new features. Please follow us!
Wow, le passage de #calckey à #firefish sous docker, quel régal, ça tourne tout seul !
Il ne manque plus que l'intégration #openID et c'est le soft parfait 🥳
I joked about the #federated thing being #RSS + #OpenID, but the truth is that RSS is still objectively the best way to get information. I just unfollowed all the stuff I don’t want to interact with here on Mastodon (official accounts, bots, etc.) and on Lenny and put some of it into my RSS reader. The advantages are many, from better design to actual independence from anything or anyone.
Pytanie do profesjonalistów. Potrzebuję w jakiś sposób logować się za pomocą kont do kilku hostowanych przeze mnie usług (m.in. #WordPress i #Nextcloud). Próbowałem to zrobić przez Keycloak i apkę Social Login w Nextcloud, ale nie ogarniam.
Czy ktoś mi jest w stanie polecić jakieś rozwiązanie, najlepiej self-hosted?
While I understand the motive for #Pixelfed 's upcoming/new Mastodon SSO, I don't like it.
It's confusing to talk about (see above). You have to word it very specifically to make it clear you're signing into Pixelfed with a Mastodon account.
The concept is confusing. It isn't the same account, by any means, and you can register on both services. Threads, for example, is more or less an extension on top of Instagram, like Guppe is an "extension" here.
I think it might be better to leave it out, just to avoid the confusion about how the accounts are linked. Instead, and to solve point 3, we could start by reintroducing #OpenID (or some form of it, like #IndieAuth ). Let Pixelfed be a provider, consumer, or both, and get more willing projects like #Calckey to support it too. That could even lend to eventually support domain-based usernames a la Bluesky, especially if Mastodon gets on board with it.
Question about implementation of #Passkeys. As I understand it, having a user login with passkey but without UV (User Verification) is not necessarily MFA as it could just be a stolen security key (Something you have).
How is (or should) #MFA with Passkeys implemented in practice? By setting UV as "required"? Or by setting UV as "preferred" and then based on the user response prompt for another factor (eg. #TOTP) in case there was no UV? I am a bit confused about how to fit Passkeys into the current #authentication logic.
I'm increasingly getting the feeling that one of these days I need to reactivate LID -- Light-Weight Digital Identity -- my entry into #identity and #iiw created more or less by accident in 2004. Then folded into the larger #OpenID movement. Some of its more interesting features were adopted by other identity protocols over time, but some others are still unique and would be very useful now that the decentralized, user-owned, social web is waking back up.
Ich habe es endlich geschafft! Ich habe den automatischen Facebook OpenID-Login erfolgreich getestet 🙂
Ursprünglich hab ich den Auto-Login mit Google probiert, das wollte aber nicht so ganz funktionieren (ähnliche Problematik wie bei Carsten), also hab ich es (nachdem mich Joss Winn mit seinem Blog-Post nochmal an das neue Facebook-Feature erinnert hat) noch mal mit einem anderen OpenID-Provider getestet und siehe da, mit myOpenID funktioniert es.
Um OpenID für Facebook zu aktivieren, muss man in den Einstellungen seinen Account mit einer OpenID verknüpfen (am Besten man probiert es mit myOpenID).
Um es zu testen, muss man sich einfach bei Facebook (bloß nicht bei myOpenID, sonst funktionierts natürlich nicht) abmelden und wieder auf „http://facebook.com“ gehen und schwups… wird man wieder angemeldet… ganz automatisch… ohne etwas zu tun…
Das klingt ironisch? Ist es auch ein wenig… Facebook scheint sich vor dem Abmelden den OpenID-Provider in einem Cookie zu merken um, beim erneuten aufrufen der Facebook-Seite, den hinterlegten OpenID-Provider zur automatischen Anmeldung zu verwenden.
Das hört sich ja erstmal nicht schlecht an, aber… das ganze System funktioniert leider nur, wenn das oben erwähnte Cookie vorhanden ist. An jedem neuen PC muss man sich also zuerst bei seinem OpenID-Provider, dann (auf klassische Weise) bei Facebook anmelden um dann, nach einer Abmeldung das Cookie zu erhalten.
Als Erweiterung zu einem klassischen OpenID-Login ist Facebooks Auto-Login sicherlich keine schlechte Idee, die derzeitige Lösung ist aber leider eher verwirrend und keine wirkliche Erleichterung für den klassischen Facebook-Nutzer. Allerdings steht Facebook ja noch am Anfang der Implementation. Es werden sicherlich noch einige Features (zumal Facebook die OpenID-Registrierung ja schon angekündigt hat) folgen und kreativ ist die bisherige Idee allemal.
Mal gespannt, wie die fertige Implementierung aussieht!
In den letzten Tagen hat Facebook einige so spannende Ankündigungen gemacht, dass ich sogar kurz mal meinen Umzugsstress unterbrechen und darüber bloggen muss 🙂
Die Facebook Open Stream API
Die erste Ankündigung betrifft Facebooks der spätestens seit dem letzten Redesign das zentrale Feature von Facebook geworden zu sein scheint. Mit der Open Stream API führt Facebook diese Strategie fort und öffnet die Aktivitäten auch für externe Applikationen und Services. Besonders lobenswert ist, dass Facebook neben einer proprietären API (zum lesen und schreiben) auch einen Atom-Feed+Activity Extension1 zum weiterverarbeiten des Activity Streams anbietet. Leider ist aber auch der Atom-Feed über den Facebook-Authentifizierungsprozess geschützt und kann dadurch nicht ohne weiteres mit z.B. einem Feedreader abonniert werden.
Dass Facebook die proprietäre Open Stream API entwickelt, statt die OpenSocial RESTFul API einzusetzen ist leider zu verstehen, immerhin ist OpenSocial als Googles Antwort auf die Facebook-Apps entstanden. Schade!
OpenID Login
Als Facebook letztes Jahr der OpenID-Foundation beigetreten ist, um sie speziell in Sachen Usability/User Experience zu unterstützt, hatte ich natürlich große Hoffnung, dass Facebook in naher Zukunft auch selbst auf OpenID umstellen würde. Seit Montag ist jetzt klar, dass Facebook an einem OpenID-Login arbeitet, der hoffentlich auch irgendwann ein fester Bestandteil von Facebook-Connect wird.
Aber Facebook wäre nicht Facebook, wenn sie einfach nur einen klassischen OpenID-Login umsetzen würden. Wie Carsten Pötter auf SpreadOpenID beschreibt, plant Facebook eine Art OpenID-Auto-Discovery:
Facebook will automatically check to see if users have logged into any OpenID account when they hit Facebook.com, and give them the option to automatically login to Facebook without entering new information.
Leider ist dieses Feature, wohl nicht global für alle OpenID-Provider und definitiv nicht ohne Directed Identity möglich… aber man wird sehen (vielleicht spinn ich hier im Blog demnächst mal ein paar Szenarien (Worst-Cases) durch).
OpenID ist ab der Drupal Version 6.0 in das Core-System integriert und muss nicht mehr per Plugin nachgeladen werden:
OpenID support is built in, making it even easier for your visitors to become a member of your site. OpenID is a free and easy way to use a single digital identity across the internet. With OpenID, login to all your favorite websites and forget about the online paperwork.
Mit MovableType gibt es jetzt zwei weit verbreitete CM/Blogging Systeme die OpenID nativ unterstützen. Das bisher hauptsächlich in zentralen Services oder Communities (z.B. dopplr oder ma.gnolia.com) eingesetzte Login-System könnte durch die oft auch im privaten Bereich verwendeten CMS/Blogging Tools den Nutzen von OpenID nochmal enorm steigern.
Leider hab ich bis jetzt nicht herausfinden können in wie weit auch AX oder SREG unterstützt werden, vielleicht weiß es ja jemand von euch…