What is Reddit's opinion of
OpenID?
From 3.5 billion Reddit comments
➔ OpenID website
By popularity on Reddit, this Service is:
37 reviews of this app found across Reddit:
> Because the authentication layer and other requirements of OAuth 2.0 are abstracted, this could lead to interoperability issues.
OpenID Connect is a pretty well defined and utilised protocol for identity (authentication).
> For these reasons, it is not safe or accurate to assume that OAuth 2.0 fully and directly supplants OAuth 1.0a
No, but OpenID Connect + OAuth 2.0 certainly do.
This entire article reads like a justification for why they haven't bothered to keep up with the times.
First of all, never save the user's password in plain text. Never send sensitive data over http, nor within a GET parameter.
Calculate a hash from the password client-side, then send that over https to your server, which will then see if it matches the hash stored in your account db. This way your server doesn't have to store the actual password.
But really, you should be looking into proven auth libraries instead of brewing your own. There's no point in exposing both the server and the user's personal info to malicious attackers, just because you thought you can take care of security by yourself. Well, not until you're actually good at it anyway. Personally, I'd go with OAuth. There's also OpenID, and lots of other options, depending on the server framework you're using.
Most web sites should not run their own authentication, because the operators of most web sites cannot be reasonably expected to keep user accounts secure.
Users can be expected to do dumb things like reuse their passwords — so if you store users' passwords and you get hacked, you just leaked the passwords that they are reusing all over the place. And under data protection laws in a lot of places, you're then required to tell those users that you leaked their passwords.
("Users shouldn't do that!" is true enough, but doesn't help anyone.)
Instead, most sites should use a federated login system such as OpenID Connect to authenticate users using an account service run by a more technically capable site, such as Google or even Reddit.
So really, your question should be: Why isn't OpenID Connect in the standard library?
I shouldn't have to remember a hundred different username/password combinations. Companies should be using OpenID/OAuth for their authentication systems instead of rolling their own.
In the distant future, I hope to be able to log in to any service I want using a single password and a fingerprint scan.
As a user, I think this would actually annoy me. I don't want your random password. It seems a bit annoying to have to reset it myself. Also, how do handle issues with non-delivery? If I don't get my password (or lose it), what then?
If you don't want to deal with confirming users, let somebody else do it. Try OpenID or Mozilla Persona. Almost everyone already has a confirmed account at some major service, and a lot of these services expose some authentication API. Why not take advantage of that?
If you don't want to use a third party, at least let users select their own password. Use a flow where a user registers with email and password and is immediately logged in to use the service. In the background, send an email with a confirmation link. The user can use the service right away, but has to confirm before they log in again. It's the same effect as your flow but less annoying.
If a non-confirmed user tries to log in, prompt them for their confirmation code and have an option to resend the email. This will help greatly with non-delivery issues, and the user will know exactly why they can't log in yet instead of just failing the login.
> holy crap OAuth sucks. No argument from me there. Anyone who's tried to implement it knows the pain. At least it's not SAML.
Here's the thing about authentication and authorization: It all sucks. There's no such thing as a simple authentication protocol, and I sincerely doubt there ever will be.
Why? Because:
- People want apps to know who they are without disclosing personal information.
- Auth presents a juicy target for hackers.
- Identity management is a hard problem with dire consequences upon failure.
OAuth is particularly bad in this respect, but only because:
- It codifies the varied approaches to authorization already in use, and
- Developers shoehorned authentication on top of the protocol.
If you want a more rigorous approach, use OpenID Connect (and please don't implement it yourself). This builds a rigorous SSO layer on top of the OAuth flow, including protocols to obtain the security tokens used by OAUTH2.
This login feature is somewhat deceitful. Yahoo works with OpenID for this login feature. It doesn't quite log you in using your Gmail account, but creates a new sudo-Yahoo account that uses your google login information as your username and password (though it can also be bound to an existing Yahoo account - I do not recommend). Using this login method, you will not be able to access Mail or Messenger, or log in to and Android or iPhone applications that don't authenticate your login using Mobile Safari.
The term you're looking for is probably public-key cryptography, and its use does involve signatures.
Recognised by a few sites (notably GitHub) and protocols (notably Secure Shell), public-key cryptography has your computer log into a site by saying "here's my public key. I have the private key. log me in.", to which the server replies "okay. here's something. sign it." and then your computer sends the signature of the thing the server sent. The public key allows the server to verify the signature, which only the private key can make. (This is a grossly oversimplified view of the process.)
The main trouble is private key leaks -- you have to be very careful with your storage of the private key to avoid anyone being able to log in as you.
And if your device gets stolen, you have to issue a new key and revoke the old one. That's another complication, which the grandparent post addresses.
Some sites will support accounts registered with OpenID, which allows any URL to be an identity provider. If you set up a Web site (your own or even someone else's) to be an OpenID provider that works with private keys or smart cards containing authentication logic, you could register on sites using no password at all!
Not that I'm aware of. Some people think that PTC accounts might have access to exclusive items/rewards, but I doubt it. I'm sure Niantic is just using Google's OpenID for convenience and won't discriminate against those users.
If you centralize authentication you will always have a single point of failure. At edX we use OpenID Connect for our IDA/micro-service authentication. We are just starting to need inter-IDA communication, for which we are moving toward using JWT.
You do need to register as a "relying party" for OAuth so it's clear to the user who they are providing access to their information to, and can revoke access at some point in the future.
The distinction to consider here is that although many implementations rely on OAuth for authentication, that's not what it's for. It grants authorization to resources, one of which might be identifying data. OpenID was built specifically for authentication, there was no notion of authorization to resources, and as such there was no need to register as a relying party because there is no access that might need to later be revoked.
OpenID Connect was built to bridge these two concepts: a standard for authorization (OAuth) and and standard for authentication. Because of the authorization piece you do need to register with the provider. The spec outlines Dynamic Registration as an optional feature of the standard which I believe Google has implemented, so you don't necessarily need to do this manually.
Just saw this typo on the OpenId section:
About OpenID The official OpenID website: http://openid.net/
Other companies and websites that use and trust Facebook Connect login:
Google Yahoo WordPress VeriSign
That's fine, now. The eden picture shows up. Another thing I noticed is that passwords are sent in plaintext on registration and login. It's a tricky problem to tackle, unless you want to go through the hassle of buying a cert and enabling SSL on your domain/server...
You could use something like OpenId or, heck, even Sign in with Steam (I use that on my own shit). That way you're only ever handling tokens instead of passwords.
Doesn't OpenID Connect do the same thing without requiring your email provider to explicitly support the protocol? With OpenID Connect you prove to a site that you own an email address by signing into some other site where you have proven you own that email address (basically).
> OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
Ah, very useful. My only concern was the means of authentication. You may want to give a better explanation for what using an OpenID means instead of just assuring people that your site doesn't collect the account's data and then linking to a Wikipedia page. Might I suggest this one as it's official?
I added the "Featured" link flair to this thread so that people know that it is trusted and legitimate.
They should also add a alternative login besides Facebook. I'm a developer who recently started working with the Facebook, and it's pretty amazing to see the information that you can access with the Facebook API.
On top of that, I think it's bad for the internet to require credentials from another service. I don't want to have to depend on my google account, facebook account, or any other service to access the internet.
I haven't looked into it, but openID seems like it might be a secure and convenient alternative.
Well, to start with, I wouldn't trust anyone who imagines that Google created OpenID when they're actually just one of many companies using OpenID - though they are one sustaining corporate sponsor of the OpenID foundation.
You may find the official site has plenty more info, as well.
But aside from that, I would certainly support it being an option.
- Use OpenID, sure, why not?
- Let people create their own account on your site
- If you feel like it, facebook and other services provide a similar benefit to OpenID
It's nice if people who already have OpenID can just log in and start playing. But if not, you're forcing them to sign up for an account with some other service just to go back to your site and log in to that account. That seems unpleasant.
Many sites have a login screen that lets people pick one of several options - OpenID, blogger, facebook, or an account on the site.
I see pretty substantial differences.
While the good thing about OpenId is that it's run by an independent and hopefully trustworthy organization, it doesn't provide two-factor authentication and does give you a single identity that you use to authenticate to lots of sites.
The idea behind this, however is to have a single device that holds multiple identities and credentials:
> Users can choose how many credentials they acquire, what information is contained in each, and how much information is revealed at login. ... *For example, student Jane Smith could get a digital credential from her cell phone provider and another one from her university and use either of them to log-in to her bank, her e-mail, her social networking site, and so on, all without having to remember dozens of passwords. If she uses one of these credentials to log into her Web email, she could use only her pseudonym, "Jane573." If however she chose to use the credential to log-in to her bank she could prove that she is truly Jane Smith. *
If you prefer, you can get separate credentials for every site you do business with. So there's a single device/technology for two-factor authentication, but hopefully not a single identity that can be tracked across sites, unless you choose to use it that way.
In an ideal world, anyway, that's how it would work. Of course, the privacy danger is that once the technology exists and becomes common, a lot of sites might start requiring verified, real-name identities. Pretty soon a law gets passed saying that logging in as "zugi" is harmful to children, and anonymity and privacy are shot.
Looks like you're mixing something up.
/signin-oidc is a common path for an identity provider like Azure AD to redirect the user agent back to the application after the user has been authenticated (see OAuth 2.0 redirect_uri), while https://login.microsoftonline.com/{tenent-id}/.well-known/openid-configuration is the OpenID Connect Discovery endpoint of Azure.
> The Instance was the companies site and not the url of the application in azure.
If the instance is not login.microsoftonline.com it's possible that you are actually connecting to an instance of Active Directory Federation Services rather than Azure AD. Both offer OpenID Connect endpoints but are different products after all.
> What should the instance be set to?
If the dotnet new mvc command from the tutorial you linked works the same as the VS template wizard I used, you should have a section named AzureAd in your appsettings.json file. Mine looked like this:
"AzureAd": { "Instance": "https://login.microsoftonline.com/", "Domain": "company.tld", "TenantId": "7a09aace-...", "ClientId": "2631890b-..." }
Note that Domain could also be company.onmicrosoft.com depending on them using a cloud-only or hybrid approach.
edit: typo
Recommendation for sign up - allow sign up via google/facebook. Makes things much easier for new users, instead of remembering another password.
https://developers.google.com/identity/protocols/OpenID2Migration
Ok, I'm clear on what you are asking now. I have never seen anyone do OpenID Connect for authentication and OAuth for authorization as distinct flows. In fact, OpenIdConnect IS OAuth2, it just specifies more specific rules around how authentication is handled.
from : http://openid.net/connect/
> OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
To do what you were asking, you would need a distinct OAuth2 endpoint for each tenant. You would need to forward the JWT token from your authentication to the specific OAuth 2 endpoint for the tenant. This would represent the "subject". The OAuth2 server would then verify the JWT signature and would would issue an Authorization token for the target API. Then the client would use the resultant OAuth 2 token for subsequent API requests.
Basically the OpenId Connect token would give you access to the OAuth2 endpoints and to the base API but you would need the client to manage secondary tokens to access the tenants.
You asked earlier if there were suggestions on a different way to do this, I personally would cut out the secondary OAuth 2 endpoint and manage authorization based on Policy based access control instead. This will eliminate the number of tokens the client needs to manage and greatly simplify the api flows.
Thanks for your response. Yes, I think your sentiment is actually fairly common and like you, I appreciate the work to implement a sign-on correctly.
Have you seen Open ID? http://openid.net/
Would this be a good in-between between Google/Facebook/Twitter logins and a custom login for a specific site?
I hope you're not a tech worker. If not, then I'll explain. You would only be handing over your username. The log in authentication is done through Facebook servers. This website would then may be get limited access to your public profile.
Just looked through your profile. Looks you are in tech. Tbh it is pretty sad you are not aware of openid and it's applications.
Ah, apparently I was thinking of OpenID Connect (rather than 2.0).
>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
Cheers for the explanation. I'd sure like to see some progress made on the whole "web identity" front. So many sites require dedicated logins, and while I don't mind that (KeePass user), for most people it's impossible to keep track of.
I'd totally set up an OAuth authorization server too, if it would let me login with my own site as my identity.
I think single sign-on is outside the scope of SIOC. The purpose of SIOC is to connect related conversations across the Web, so for example if you're viewing a comment thread on a particular website, that page could display links to related content, from either elsewhere on the same site, or other social sites or forums. Single sign-on could be provided independently of SIOC, by implementing one of the applicable standards like Mozilla Persona or OpenID.
It looks like OpenID suggests several libraries for a relying party for Java. Take a look here: http://openid.net/developers/libraries/
It doesn't much matter if the user agent is HTML5, iOS, Android, or an Atari 2600. They all communicate to the web API the same way. Typically with a web API the user agent is going to be responsible for all the redirecting, the webapi just tells it where to redirect to.
Just wanted to respond back, I was actually able to get this working using the sample here: https://github.com/yohcop/openid-go/blob/master/_example/server.go
Only thing I had to do was add a "realm" on the RedirectURL function. http://openid.net/specs/openid-authentication-2_0.html#realms
The realm is the third string for the RedirectURL function.
Hope this helps!
So you want people to login with Steam ID on your site? Steam uses OpenID for authentication. If you're coding a website from scratch, use one of the provided libraries. If you're using a CMS like Joomla or Wordpress, there are plugins that you could use.
Thats what it looks like, however Ctrl-F5 does not do anything to fix it :(
The code comes up as:
<?xml version="1.0" encoding="UTF-8" ?> - <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)" xmlns:openid="http://openid.net/xmlns/1.0"> - <XRD> - <Service priority="10"> <Type>http://specs.openid.net/auth/2.0/server</Type> <URI>https://account.oneplus.net/verify</URI> </Service> </XRD> </xrds:XRDS>
To be honest, I've had to try and do this at work because I'm at work until 17:00 GMT. The work computers run a crappy version of Internet Explorer so I guess its my own fault for hoping it would work here.
I've given up to be honest, nothing I can do about it now.
The super simply version is:
Instead of logging into the rustmap.net site, you actually log into steam, and steam sends back a session ID that says your session is a valid authentication. It doesnt send any of your user login info to rustmap.net.
Here's a picture of the openID concept: http://openid.net/pres/protocolflow-1.1.png
Let me know if you want to get more technical. :)
Please if you only change one thing make it OpenID support.
I don't want to to learn some 12 digit login ID and then fifty questions. I want to put all my eggs in one basket, and then fortify that basket really well. I'm fond of Google as my Internet matériel of choice, but others may prefer Facebook, or any other OpenID provider.
It's pretty well established that Facebook and Google are much better at keeping track of us than the government is, and not to point too fine a point on it, but the existing government user authentication schemes are by global standards rather questionable. Hand-ball it to the experts.
I can point out at least two flaws in this idea, the biggest of which is that most people will want to change their password, so for them it's more work than usual.
But you know what everyone will love? OpenID. It makes everything even easier - two clicks and boom, you have an account.
(Also, Facebook Connect, but don't make that the only federated login option. Not everyone has an account.)
> Because facebook really screw people over by changing their API without warning.
I can see that being annoying.
Though I would imagine that there's pre-existing software, and you'd just grab an update any time the underlying API was changed.
If not, and if I cared, I'd make an abstract facebook API wrapper and obsessively watch for changes. ;)
Also...
> Many OpenID providers collect and share a wide range of demographic information, including name, date of birth, location, gender and an email address. This data allows you to optimize your marketing efforts and tailor your website to better target the needs of your core audience.
Bad news - the internet officially sucks for privacy. ;)
> Open source protocols such as Portable Contacts can be used with OpenID to offer your site access to a user’s address book and friends lists.
And I used to think that OpenID was a good thing.....
Is there anyway you could imgur a screenshot of how the site looks in your iPad? One of the things I want to do if I can in the future is to have something similar to reddit where it grabs a thumbnail of whatever url you're linking to.
OpenID, you may already have it. Do you use gmail? or yahoo, or flickr? then you already have one. See here: http://openid.net/get-an-openid/
As for the circle jerk: I think out of 10 votes in a critique, 1 is from the guy who submitted the item (which yeah, surely will be an upvote if the critique was the "pat-in-the-back" type), but 9 will be from people with nothing to gain nor lose from voting up or down. Hopefully these 9 votes will correspond to the quality of the feedback. In the three weeks we've been up so far, I would say 99% of all the feedback is very thoughtful and useful.
I think some sort of "culture" forms automatically once you reach a certain number of regulars. I hope if this happens for KC, it'll happen in a way that rewards quality feedback.
To be honest, I just pulled that "mysterious authentication app" idea out of my ass. I imagine it could just be a very simple command line app handling only user=>password key creation and lookup while hiding everything away in a quadruple-encrypted hidden file.
It may be slower, but probably preferable to scrambling to freeze all user accounts or being taken to court by the state of Massachusetts. It just seems an appropriate solution to many the world's website password woes... for at least a little bit.
There's already remote solutions like Openid.