[HN Gopher] Show HN: Login with HN (Unofficially)
___________________________________________________________________
Show HN: Login with HN (Unofficially)
Author : hardwaresofton
Score : 343 points
Date : 2022-01-13 17:31 UTC (5 hours ago)
(HTM) web link (loginwithhn.com)
(TXT) w3m dump (loginwithhn.com)
| adamrezich wrote:
| nice! I did a very similar thing many years ago for the video
| game website giantbomb.com. they have a wiki and you get points
| for making contributions, but there's nothing to do with the
| points, they don't do anything. so I made my own website where
| you could predict review scores they would give upcoming games,
| and "gamble" (a copy of) your giantbomb.com account's wiki
| points, which were scraped once you logged in with pretty much
| the exact same system (putting a generated hash into your account
| profile).
|
| I've always thought that this is a neat idea and similar methods
| could be used to make all kinds of cross-account connection stuff
| work on various websites. if you're making any kind of social
| site like this, allow users to have an editable public bio!
| AnotherGoodName wrote:
| This site isn't really intended for high security. It doesn't
| matter that much since Hackernews login is only for this site and
| text posts here are not that valuable. If it was expanded in
| usage it could be disastrous.
|
| The fact that the admins of this site do manual recovery for
| example is a terrible practice that no serious providers do. In
| fact the reason i'm 'AnotherGoodName' rather than my old
| AReallyGoodName is because i suffered account takeover on this
| site. The last three posts from AReallyGoodName promoting
| CoinRace are not me. The rest, including posts for my github
| projects (i still own my Github) are.
| https://news.ycombinator.com/item?id=16460663#16461236
|
| I do not think for one second that Hackernews is ready to handle
| sign ins for things that need more security than this site
| itself.
| outloudvi wrote:
| Interesting. However, it requires your trust to the service. So
| probably the identity user shall build and host such service by
| themselves.
|
| Or a more trusty solution is to make the identity verifiable. Oh,
| did I say Keybase(the former one not acquired by Zoom)?
| dougk16 wrote:
| I'm doing something very similar with my service:
| https://aytwit.com/thoughter
|
| To the author, there is a simple trick you can pull in order to
| make the confirmation instantaneous and avoid caching. Have you
| figured it out? Let me know!
|
| I also use a residential proxy service for all my profile
| requests, regardless of the identity provider. For some sites
| like Twitter, Facebook, etc. this is required, and for something
| like Hacker News it's simply future-proofing in case they decide
| to block scrapers at some point in the future.
|
| Good work!
| diogenesjunior wrote:
| >for something like Hacker News it's simply future-proofing in
| case they decide to block scrapers at some point in the future
|
| Why are you scraping? We have an API, it's linked at the bottom
| of every page[0].
|
| 0: https://github.com/HackerNews/API
| dougk16 wrote:
| Good question, and thank you for the question. Both at the
| time of my initial development several years ago, and
| including now when I just tested it, scraping has faster
| response times (cache invalidations) to profile updates than
| the API. This saves the user of my site being frustrated that
| they put the code in their profile, but they keep smashing
| the "Check again" button to no avail.
|
| To be fair the API's cache invalidation does seem to have
| improved since last time I tested it. It only takes up to
| 5-10 seconds now, but still this is an eternity to an
| impatient user.
|
| Also since you imply you work for HN, I'll give you my little
| secret: If you randomly capitalize the letters in the HN
| username it invalidates the cache. Otherwise scraping the
| profile would indeed take as long as the API approach. I'm
| taking a risk with you fixing it now. :)
|
| I hope that helps clarify and I look forward to your
| thoughts.
| hardwaresofton wrote:
| Honestly I need to use this API as well -- on the list of
| things to do. I left myself some abstraction to have
| different ways of checking and the easiest was scraping but
| honestly hitting the API would have been just as easy. Will
| fix this
| hardwaresofton wrote:
| Hey thanks for the helpful suggestion!
| ramon wrote:
| Would be interesting to come up with a nice use case now with
| this.
| hardwaresofton wrote:
| Well it's technically a usecase for itself... so there's that?
| laputan_machine wrote:
| Great idea, I like the concept of using a code in your bio as the
| auth mechanism. As another poster replied, the api seems to be
| 500'ing
| krapp wrote:
| As far as I know, IndieAuth[0] is the open source solution for
| this.
|
| I've wondered how well it would work on a forum like HN, both
| for account authentication (making the forum simpler by not
| requiring passwords) and for identity validation when necessary
| (for example, highlighting the owner of a project or site.)
|
| [0]https://indieauth.com/
| hardwaresofton wrote:
| Hey would you mind giving it another shot?
| laputan_machine wrote:
| Tried again, got a lot of 201s with:
|
| ``` {"status":"success","data":{"confirmed":false}} ```
|
| Then a failure with a 502, I'll check it on a different
| network tomorrow to see if it's on my end
| hnarn wrote:
| This is kind of reminiscent of how keybase verifies your
| ownership of social media accounts, domain names etc.
| zemnmez wrote:
| it seems like if this is OAuth2, the protocol is not giving an
| audience specifier? That would mean that any token is as good as
| any other, and say, authenticating to evilsite.com, the site
| could use the token its granted to itself log onto another 'login
| with HN' website as the victim. Thats the usual issue with OAuth
| as login
| hardwaresofton wrote:
| Ah yes, this is something I'm going to tighten up once we have
| OAuth2 clients signed up -- right now the only client is the
| actual loginwithhn site itself!
| rank0 wrote:
| Thanks for pointing this out. Reading your comment just
| connected some dots in my head about the OAuth flow.
| tomhallett wrote:
| Question - are you affiliated with HN/YC at all? If not, I would
| be concerned about the colors/branding on the homepage being the
| same as HN/YC. I see the word "unofficially", but it feels like
| there still might be some confusion of how it relates to YC's
| software.
| hardwaresofton wrote:
| Nope not affiliated at all! I thought "unofficially" was enough
| but I'll make it a bit more clear
|
| [EDIT] I added another disclaimer
| tomhallett wrote:
| Very cool! That's what I had in mind.
|
| Agreed that you added "unoffically", but you also created a
| new method todo login (vs cookies/oauth2/etc), so I wasn't
| sure how to map the "unoffically" word with your novel
| approach. Your disclamer makes it very clear. :)
| hardwaresofton wrote:
| Thanks for bringing it up, glad to correct it!
| version_five wrote:
| Congrats on putting this together, it looks really cool.
|
| One suggested feature that crossed my mind is to allow a minimum
| karma or account tenure requirement, in order to screen for
| throwaway accounts in cases where this mattered.
| hardwaresofton wrote:
| That's a fantastic idea, thank you, I'll implement that.
| quickthrower2 wrote:
| Nice. Its the equivalent of domain name verification using TXT
| records, but for HN profiles!
| Minor49er wrote:
| It didn't appear to be working after a couple of attempts.
| Opening the console shows a lot of HTTP 500 responses coming from
| /api/v1/hn/poll/status
| jmkim wrote:
| +1 Having same issue here
| hardwaresofton wrote:
| Hey would you mind trying again?
| Minor49er wrote:
| The API is responding that the request completed
| successfully, but it doesn't appear to authenticate. I even
| tried replacing my entire About section so that it was only
| the code and it didn't appear to recognize it
| hardwaresofton wrote:
| Shit good thing I didn't go to sleep, looking at it now
|
| [EDIT] - OK just pushed a new version -- it looks like it was a
| load issue, were you able to get in?
|
| [EDIT2] - Welp, looks like sleep isn't happening, looks like
| it's load triggered but there are some failures happening... I
| don't like this hug.
|
| [EDIT3] - We got 'em boys. Found the bug, rolling out now.
| motohagiography wrote:
| Using forums as pseudonymous identity providers is a _very_
| powerful idea. It 's essentially community federation. There is
| of course risk that your IDP chucks your account and you lose
| access to the other ones, but that's solvable with a recovery
| scheme.
|
| Lightweight, low assurance credentials probably have the biggest
| growth future, as if universal high assurance credentials were
| really that commercially desirable, we'd already have them. These
| are a kind of affinity credential, which has a lot of
| optionality.
| dougk16 wrote:
| It's a powerful idea but say I'm a website that wants to add
| "Sign In With HN". Me personally I've lost faith with "Sign In
| With Facebook/Google/etc.", nevermind some random site offering
| sign ins with random forum identities. As a website owner, I
| would have to trust that the "Sign In With HN" service would
| still be there in a month or two, nevermind a year or two. If I
| wanted to create such an SSO service, what kind of reasonable
| social/technical guarantees could I make to website owners so
| they'd be confident I'd be around for the long haul?
|
| A better technical solution would be to offer an SDK that does
| the same thing that websites could integrate themselves, but
| then you have the explosion of languages and frameworks to
| support.
| motohagiography wrote:
| This is the good part. I'd rather avoid the SDK case, as I've
| run down that road before and it's fraught.
|
| If you affinity federate to HN, (or even a subreddit), and
| you create a recovery process that enables the user to
| migrate their local identity on our app to a new IDP,
| realistically, you could just federate to anything someone
| can store a key on, if you wanted to. The security of the
| users account is up to the user.
|
| If I want to bind my user account on your SaaS app to
| anything persistent online that I have control of, that
| should be sufficient for most low assurance purposes.
|
| The lightweight security of it is that if I enroll/register
| for your app as motohagio@location.public_key, my password
| for your site becomes just a random string encrypted with my
| private key, as that proves my possession of the private
| complement used for registration when you decrypt the string
| using the contents of the public key location I provided
| during enrollment. A lot of protocols already essentially
| look something like this, they're just not described in a
| casual comment.
|
| The lightweight security of the system isn't based on the
| secrecy of passwords, but rather, a combination of the
| secrecy of the users private key and the integrity of the
| registration pointer to that public key. It still works with
| browser passwords, as instead of a password string, you
| submit {randomstring, (randomstring)^privkey_privkey} and the
| RP app just looks up its registered public key pointer, and
| makes sure the random string in the ciphertext matches.
|
| Problem it solves is net-net it shifts risk off your service,
| onto the user, and removes a single point of user compromise
| for all users at once. You can federate your service to any
| document on the internet that persists a public key, and
| account compromises don't scale the same way.
|
| The most obvious vulnerability is the integrity and
| availability of the location and directory services of that
| public key location. But cacheing and recovery schemes could
| make it viable. (some people will be apopleptic at the mere
| mention of it, but it's a use case for the chains made of
| block)
|
| I've done the high assurance use case design on a variety of
| other products, but maybe the low assurance case is the one
| that's actually useful. Irony is it may still require a
| password manager / authenticator client for most users, but
| in the majority of logins, you can still save this new token
| in your browser as a password.
| simonw wrote:
| This is a smart implementation. I was worried it would be doing
| something uncouth like asking for your HN password or scraping
| some kind of unofficial API, but instead it gives you a token to
| embed in your public profile - so it's still scraping your
| profile page, but that feels like a very low-impact way of
| building this.
|
| Suggestion: on the "Put the token below in your HackerNews
| Profile" page, rather than polling to see if the token has been
| added (which is a bit rude) add a button for "I have added this
| token to my profile" and only check once the user clicks that
| button.
| dheera wrote:
| > doing something uncouth like asking for your HN password
|
| Yeah I was worried about this too, it's a disturbing trend.
|
| Venmo was asking for my bank password a couple months ago, I
| was like fuck no. Who the HELL does that. Should be illegal to
| even ask.
| simonw wrote:
| I complained about that Venmo thing on Twitter and got an
| interesting conversation going about it, including with
| comments from the CTO of Plaid who are the company who built
| that integration.
|
| https://twitter.com/simonw/status/1479174549266526209
|
| Short version: OAuth for banks is finally starting to happen,
| but in the meantime the password anti-pattern fills the gap.
| KoftaBob wrote:
| In the case of venmo (and many other of their customers), it
| was actually Plaid that was asking for your bank login
| credentials to connect your bank account to Venmo. They've
| been getting criticism regularly for that, unsurprisingly.
| dheera wrote:
| Yeah so now I need to give my password to not just Venmo
| but also some startup called Plaid that I need to trust?
|
| Doubly fuck no.
| zwily wrote:
| Plaid is not some tiny startup... They're almost 10 years
| old and Visa tried to buy them for $5B a couple years
| ago.
|
| That doesn't mean you should trust them (I don't), but
| just because you haven't heard of them doesn't mean
| they're not big.
| Operyl wrote:
| Venmo offers the traditional verify a deposit amount
| validation method too, it just takes a few days. It's an
| either or method.
| phoenixy1 wrote:
| To clarify -- Venmo doesn't get the credentials at all,
| only Plaid does. Venmo then uses an API to get the
| specific bank account data it needs from Plaid.
| dheera wrote:
| I still don't trust Plaid.
|
| Venmo could also get the credentials if they want to,
| since they're launching it from within their own app.
| They could keylog everything in their app if they wanted
| to, including what happens inside Plaid.
|
| Nobody should ask for passwords to anything but their own
| service. Period.
|
| Asking for bank passwords should be made illegal. If I
| were the president I would have made that a federal law
| yesterday.
| floatingatoll wrote:
| (And Plaid noted that they vastly prefer to oauth to banks,
| and do with many other banks, but that Venmo won't accept
| oauth and demands credentials.)
| Operyl wrote:
| No that's not correct. Venmo is not forcing password
| auth, it's banks not implementing the OAuth flow that
| causes this. I just went through with OAuth in Venmo with
| my bank (Capital One). They also offer traditional
| (deposit 50 cents and validate the amount) work flow too,
| they're not forcing the Plaid model at all.
| waffle_maniac wrote:
| What about a cryptographic signature? That might be nice.
| rsync wrote:
| "... I was worried it would be doing something uncouth like
| asking for your HN password or scraping some kind of unofficial
| API, but instead it gives you a token to embed in your public
| profile ..."
|
| I have a side project I've been kicking around for a while that
| required some kind of reputation/login/accountability function
| and this was exactly what I considered doing: giving people a
| token to put into a public HN profile.
|
| So anyway, great job Victor!
| hardwaresofton wrote:
| Hey if you don't mind I'd love to have you kick the tires --
| there aren't any client apps (other than the website itself)
| right now, but I'll be opening that up soon, got some bits to
| batten down like audience and registration forms.
| rsync wrote:
| So, so pessimistic that I can carve enough time away from
| rsync.net to start this new initiative ... but we'll see
| ...
| hardwaresofton wrote:
| rsync.net is a massively awesome product, I think I can
| safely say the rest of the internet is hoping you don't
| get any time away :).
| irthomasthomas wrote:
| The tyranny of success.
| freedomben wrote:
| Agreed, and it doesn't really matter but for some reason I felt
| compelled to mention, this same mechanism (putting token in
| profile page) has been in widespread usage for years so isn't
| novel. Keybase is one example.
| tiffanyh wrote:
| Even before that, this is a common practice with DNS for
| decades to prove ownership of a domain.
| curiousgal wrote:
| SPF
|
| DKIM
|
| Let's Encrypt Certificates
| sattoshi wrote:
| For all the obscure examples of prior art being given in this
| thread, this is also how Keybase did proofs with HN.
| clay-dreidels wrote:
| This is very clever. On a side note, I wish HN offered two-
| factor authentication.
| iyn wrote:
| +1, would be nice to have 2FA
| kogir wrote:
| Just pick a good password and don't reuse it elsewhere. HN is
| super aggressive about rate limiting attempts, so brute force
| isn't really a risk.
| tlarkworthy wrote:
| the exact user flow for a third party Auth system in
| Observablehq
|
| https://observablehq.com/@endpointservices/login-with-commen...
|
| all code is ISC licensed and both the server and client is
| embedded in a web notebook
| johnkpaul wrote:
| I totally agree with you and I was also worried about uncouth
| behavior. That said, and not to undercut the smartness here, I
| have memories of this being the main mechanism to authenticate
| third party services to the SomethingAwful forums.
|
| I have vague memories of thinking through how scraping could be
| used for much easier global authentication and then quickly how
| that was probably a dumb idea.
| nvr219 wrote:
| Yep, I still do this with gbs.fm!
| dmix wrote:
| What is gbs.fm if you dont mind me asking?
| gresrun wrote:
| Some quick Googling yielded: https://forums.somethingawfu
| l.com/showthread.php?threadid=38...
| nvr219 wrote:
| A community radio station where you have to be a
| somethingawful member to access.
| Lorin wrote:
| Have you considered playing more Journey? :^)
| tomphoolery wrote:
| this site is the last place i thought i'd find a gbs.fm
| reference
| tata71 wrote:
| Instead, the token (a text string) will be an "object" (a non
| fungible token) that you prove is in your wallet with zk
| proofs,
|
| wallet being on whatever chain(s) decided upon as ubiquitous
| in the coming year.
| floatingatoll wrote:
| I assume this is /s and I laughed when I read it. Well
| played.
| meowkit wrote:
| It's not sarcasm, and it is what some communities want to
| achieve with decentralized identification.
|
| https://www.microsoft.com/en-
| us/security/business/identity-a...
| colinclerk wrote:
| Wow, awesome! We've had a few startups ask for an HN integration
| at https://clerk.dev and we'll build this in ASAP.
|
| It would be great if this could somehow verify whether an HN
| account has been part of YC cohort. A few requests we've received
| were with the hope of offering early access to YC founders-only
| before a public release.
|
| Also, I love the OTP solution instead of asking for our HN
| passwords.
| hardwaresofton wrote:
| Hey thanks -- I will definitely be sending you an email soon!
| jrs235 wrote:
| This is awesome! I had this same idea just last week! Way to
| execute!
| kotrunga wrote:
| "I'm a yak shaver by trade"
|
| Nice.
|
| Do you have any sites that support the flow yet?
| hardwaresofton wrote:
| None yet! If you would like to be the first please reach out or
| use this subscription form:
|
| https://mailing-list.vadosware.io/subscription/form
|
| (Ignore the mailing list bit). If you're able to log in there's
| a more direct form at the end of the flow!
| spockz wrote:
| I'm not sure why this couldn't function as oauth provider for
| HN. Why does it support a new flow?
| hardwaresofton wrote:
| Yup that's the hope/intention -- If you have an app I can add
| you as an OAuth2 App (the registration page isn't up yet, but
| it will be soon)!
| azalemeth wrote:
| Is the author a literal yak shaver, a la sheep-shearer, but for
| yaks? (Or is it perhaps another way of saying "I can't legally
| tell you what I do for a living"?)
| djrogers wrote:
| https://en.wiktionary.org/wiki/yak_shaving
| michaelt wrote:
| It's a reference to
| https://en.wiktionary.org/wiki/yak_shaving
|
| The author is saying "Yes, I know I've built something that's
| not very useful here"
| azalemeth wrote:
| Thank you! I'd never heard that particular phrase before.
| udbhavs wrote:
| Great idea. If you need to add a code to your bio, another idea
| is putting a public key in your HN bio and signing a nonce
| message using some browser extension like Metamask.
| dividuum wrote:
| Wouldn't it make more sense to store a blob containing the
| username, signed by loginwithhn in the profile. Something like
| HMAC(secret_kept_by_loginwithhn, username). Upon authorization,
| check if the blob is properly signed and matches the requested
| username. That way you'd only have to place it once and copying
| it between profiles isn't possible. I'm probably overlooking
| something.
| jtsiskin wrote:
| This trusts loginwithhn. The metamask way can be used by any
| site and only need to trust hacker news.
| Anunayj wrote:
| Or just storing the key in browser with Web Crypto API (or
| localStorage cuz safari ffs). Ofc this means the key is only
| scoped to their domain.
| clay-dreidels wrote:
| This is a smart, safe implementation. On a side note: I wish HN
| offered 2FA.
| lostmsu wrote:
| I wonder if this concept could (and perhaps should) be extended
| to be OAuth provider, that lets you in based on ability to
| control content under arbitrary URL. Maybe even standardized
| somehow by exposing meta tags in the HTML header.
| paxys wrote:
| This is neat. How do you protect against a third party scanning
| HN profiles for codes and stealing them?
| hardwaresofton wrote:
| Ah, so because the login challenge is unique, the person would
| have to have access to the browser that received the original
| login challenge -- there's a second second secret when you
| initiate login (that's part of the bit managed by ORY Hydra)
| maliker wrote:
| Awesome documentation!
| [deleted]
| gruez wrote:
| >How does it work?
|
| >[...]
|
| >LoginWithHN generates a unique one-time-use code that the user
| must then put into their profile within 5 minutes
|
| I like the implementation, but shouldn't the code be something
| more explicit? Otherwise it might be easy to social engineer
| someone into putting in the code. Currently it's
|
| >Put the token below in your HackerNews Profile /
|
| >[random letters]
|
| I think Keybase does something more explicit, with something like
| "my keybase verification code is xyz"
| hardwaresofton wrote:
| You're right -- I will make this more explicit to hopefully
| prevent some phishing attempts
| colinclerk wrote:
| I agree this is a concern, though more with phishing than
| social engineering.
|
| An attacker site pretends to have their own "Login with HN"
| implementation, but asks users to put in a code generated from
| LoginWithHN.com itself.
|
| If the user adds the code, then the attacker can impersonate
| the victim on any service that supports LoginWithHN.com
| (because of the special second-time login handling)
|
| If the string was more explicit that it's for LoginWithHN.com,
| the victim is more likely to recognize that something phishy is
| going on.
| hardwaresofton wrote:
| Thanks for the suggestion, this is a great idea. The phishing
| angle is not one I had considered
| metabagel wrote:
| Blocked by both Firefox and my company due to certificate issue.
| metabagel wrote:
| Actually, looks like you are on a malware blacklist.
| hardwaresofton wrote:
| Could you tell me more about the blacklist? is it IP based?
| URL based? The servers are in Germany under Hetzner so maybe
| it's an IP ban that went in
| todd3834 wrote:
| Very cool, I was experimenting with a similar implementation of
| this a few years back. We were using a browser extension to
| handle the posting to the profile for you. However, we noticed
| that that profile was cached on the server so you would end up
| having to wait a long time to get a new version. I believe we
| tried appending a random query param to cache bust but the server
| didn't seem to care about that.
|
| Have you ran into this? If so, how did you get around it?
|
| [Edit] Here is a link to the now dead project :(
| http://web.archive.org/web/20161225152153/http://www.clap.ch...
| We briefly mention how it worked but didn't go into full detail
| hardwaresofton wrote:
| Right now I'm actually just waiting a long time and checking
| somewhat slowly -- there's a note that it might take up to 1
| min. I'm more concerned with not causing trouble for the staff,
| and usually it's about <1min so not the end of the world I
| think
| dougk16 wrote:
| I'm doing something similar with my service
| https://aytwit.com/thoughter
|
| There is a trick to busting the cache but I almost don't want
| to say it in case they fix it lol. Feel free to contact me
| directly.
| hardwaresofton wrote:
| Hey thanks for this note :)
| [deleted]
| hirundo wrote:
| I can speak more freely on a forum if my logins are independent.
| If they are federated I have more to lose by saying the wrong
| thing. There are scarcely any values I can express without
| offending someone. For this purpose at least, it looks like a
| better strategy to have multiple isolated credentials. With a
| password manager the inconvenience almost disappears.
| xtracto wrote:
| Right, in addition to that, I am currently in the process of
| de-Googlifying and de-Facebookfying all my logins. I prefer the
| tired and tried method of having a separate login and password
| for each account, and save them on KeePassXC.
|
| There have been plenty of horror stories of people that lose
| access to their Google or Facebook account, and suddenly cannot
| access their connected accounts.
| hardwaresofton wrote:
| Hey HN,
|
| I wanted to be able to make apps that do social login with HN so
| I hacked it together.
|
| It works like you would expect -- generating a code you can put
| in your profile. For convenience, you can then use either TOTP or
| Email (if you specify both, it will default to using TOTP) to
| login thereafter to make things quicker (it can take up to a
| minute until profiles update).
|
| I generally wait about 5 seconds between checks of a profile,
| hopefully this isn't too much additional strain (especially since
| I expect most people to switch to something faster after the
| first login).
|
| [EDIT] Also it's night time (well morning I guess) where I am
| so... spinning up some more instances and I'm going to sleep.
|
| [EDIT2] My email is plastered all over the site, but please feel
| free to email me any bug reports!
|
| [EDIT3] If you'd like to register an app, please check out
| https://mailing-list.vadosware.io/subscription/form ! Ignore all
| the other mailing list stuff and get on the "early adopters" list
| for LoginWithHN! Or just email me in my HN profile, whichever!
| dang wrote:
| > I generally wait about 5 seconds between checks of a profile
|
| If you're scraping HN, please wait 30 seconds
| (https://news.ycombinator.com/robots.txt) - our app server
| still runs on a single core, so we don't have a lot of
| performance to spare. (Hopefully that will change this year.)
|
| If you need to check more frequently,
| https://github.com/HackerNews/API works fine and you can get
| JSON that way anyhow.
| will0 wrote:
| > you can then use either TOTP or Email (if you specify both,
| it will default to using TOTP) to login thereafter to make
| things quicker (it can take up to a minute until profiles
| update).
|
| I guess at this point it's more like login with loginwithhn?
| shreddit wrote:
| More like register with loginwithhn?
| hardwaresofton wrote:
| Yup! LoginWithHN is the OAuth provider :) so the idea is if
| you have an app that you want people to use to login with HN,
| _via_ LoginWithHN then you can use loginwithhn.com to make it
| happen
| Visayer wrote:
| Victor, congratulations on the launch! I am one of the
| maintainers at https://github.com/ory/hydra and it makes me super
| happy to see that Ory Hydra is being used for such innovative
| projects :)
|
| If you're interested to join Ory, we'd be excited to have you!
| Drop Aeneas a line and he'll take it from there: aeneas@ory.sh
|
| Hopefully we'll talk soon :)
| hardwaresofton wrote:
| Hey I appreciate it! It's a tiny little hack but I'm glad
| people seem to like it! ORY Hydra was fantastic every step of
| the way, I originally started with a completely different
| tool/approach actually then switched to Hydra and rewrote
| things and it was way smoother. Thanks for the awesome tooling
| you make.
| Visayer wrote:
| Appreciate the kind words! :)
___________________________________________________________________
(page generated 2022-01-13 23:00 UTC)