Check out the open source code on GitHub: https://github.com/panther-labs/panther
HN user
willow9886
I tend to prefer the style GitHub has gone with. Easier to quickly identify new features of interest.
Would be great to be able to "upvote" features.
Clickable repo link here:
Also consider that, should Apple choose to eliminate your account, then you've lost whatever you use Apple to sign in with unless those downstream providers offer some kind of recovery mechanism.
Yes, some kind of recovery mechanism, some ability to set a local credential post-registration, or some ability to link and unlink external accounts, e.g. Sign in with Apple, then link your Google, FB, and Github accounts. Then, if you lose access to your Apple account, you still have additional options for authentication.
The latter two options are something I wish more organizations offered..!
For those of you interested in this topic, check out Internet Identity Workshop: https://internetidentityworkshop.com/
Great little "un-conference", hosted semi-annually in Mountain View, CA. Where a lot of the nuts and bolts were worked out for OpenID Connect.
In fact, today IIW 29 is coming to a close. Next gathering in April, 2020.
Basically, if you're a large org, you must be an OpenID Provider (OP). Optionally, you might also be a consumer.
If an org supports social login, for instance, they are likely a consumer and a provider.
The user authenticates at an external OP (like Apple or Google), but a local account (or "identity") is always created by the service provider, which should be stored in an OpenID Provider.
but it's ultimately an identity that Apple owns.
I would say that's slightly inaccurate.. it's ultimately identity information that Apple owns. And of course, Apple owns your account with Apple.
But the minute you "sign in with Apple" to any service, they too are creating a local identity for you (sans password). That identity begins with the information provided by Apple (e.g. name, email address, etc.), but can expand over time to include additional information provided by the user, not Apple.
Gluu writes its own software, like the OAuth2 Authorization Server, oxAuth, and bundles other open source software like the Shibboleth SAML IDP.
Why not a cloud provider like Google Identity, Okta, OneLogin, etc?
The Gluu Server bundles a fork of OpenDJ 3.0 for persistence, the last open source build. It also supports OpenLDAP, and will soon support Couchbase.
Why? If an author or maintainer of a FOSS project wants to highlight their own work, so the community might too benefit, what's the issue?
My partner Mike Schwartz founded Gluu because he was tired of recommending proprietary access management platforms like Siteminder and IBM Tivoli that were locked behind six figure licenses.
We're now a team of about 30 people with 10 years of development into the Gluu Server, a free open source software platform for SSO, 2FA, access management:
GDPR actually applies to all EU citizen data, regardless of where the citizen resides.
"If your enterprise has a presence on the internet in the form of a website and if your enterprise collects personal data from customers regardless of where those customers are located, it is subject to the provisions of the GDPR." [1]
[1] https://www.techrepublic.com/article/the-eu-general-data-pro...
Seriously? How about Google?
https://developers.google.com/identity/protocols/OpenIDConne...
Yes they do.
See here:
https://accounts.google.com/.well-known/openid-configuration
And as far as I know, Facebook doesn't support OpenID Connect. They still roll their own custom OAuth2 implementation.
Many sites are doing identifier first authentication, incuding google.
When you login to google, it prompts you for an email address first. If your email is associated with an organization that has configured Google Apps to use their OP for authentication, Google will redirect the user to their home domain based on the email.
no, but using my email adress @gluu.org, you can find the discovery endpoint because its a standard address for domains. For instance, here's Google's OP discovery endpoint:
https://accounts.google.com/.well-known/openid-configuration
oops! i've been staring at the screen too long!!
OpenID Connect defines two important standards: Discovery [1] and Dynamic Registration [2].
All OpenID Providers publish their details at a publicly discoverable (and standard) domain: https://{hostname}/.well-known/openid-configuration.
For instance, you can see our OP meta data here [3].
This provides the foundation for using email as an identifier, i.e. in order to access protected resource at autonomous site, input email at a domain with an OP, and the RP can perform discovery to find where to send the user for authentication, and dynamic registration to register their client (app) with the OP to obtain user information ("claims").
[1] https://openid.net/specs/openid-connect-discovery-1_0.html
[2] https://openid.net/specs/openid-connect-registration-1_0.htm...
Nobody said it was...
OpenID has been replaced by OpenID Connect
Replaced != compatible.
Also, "traditional OpenID" is very ambiguous phrasing... are you referring to OpenID 1? OpenID 2? or OpenID Connect?
It's a bit strange that nowhere in the post does SO mention OpenID Connect...
OpenID 1 & 2 have been dead and deprecated for some time...Google deprecated support in 2016.
All domains should move to supporting the latest iteration, OpenID Connect, which, by all indications, looks like it will be stable and relevant for many years to come.
No, OpenID has been replaced by OpenID Connect, a profile of OAuth 2.0 written to specifically address user sign in.
OAuth 2.0 is an authorization framework, not an authentication protocol. OAuth 2.0 can be used for a lot of cool tasks, one of which is person authentication.
OpenID Connect is a “profile” of OAuth 2.0 specifically designed for attribute release and authentication.
For more info, see our blog: OAuth vs SAML vs OpenID Connect. [1]
[1] https://www.gluu.org/resources/documents/articles/oauth-vs-s...
I don't get why OpenID was introduced in the first place then.
Because the Internet needs standards to work. If all domains implement authentication differently, we do not have an interoperable network.
As is customary, standards must evolve to keep up with requirements. OpenID 1 and 2 weren't built with the idea that smart phones would be in every persons pocket, or Internet connected devices in every home.
The latest iteration of OpenID--OpenID Connect--is essentially Google's playbook for authentication. It's of huge value to the rest of the world.
To put it simply: having your own OpenID Provider at your domain (e.g. idp.example.com) allows you to operate a similar authentication infrastructure as Google.
What does that mean?
- Single sign-on (SSO) across web and mobile applications
- Ability to support a variety of strong authentication mechanisms (a.k.a 2FA), like U2F security keys and OTP mobile apps, in one place for many apps
If all apps and services were to align with OpenID Connect, we would have a truly scalable and interoperable identity layer for the Internet.
Don't forget they're also monitoring people who interact with you (a.k.a. the user of services).
When I walk into a friends home who has an Alexa, or a Ring system, it is now tracking me too.
The purchaser consented, but I never consented to being monitored in a residence/dwelling where I would otherwise have the reasonable expectation of privacy!
There was a good Gizmodo article about this called The House That Spied on Me [1].
[1] https://gizmodo.com/the-house-that-spied-on-me-1822429852
nice work, Dropbox.
Regarding Q1:
Under state law, access to voter data is restricted; however, journalists, political campaigns, and academic researchers can acquire the data for certain purposes.
I guess the question is, what are the "certain purposes"?
I had just posted this GDPR guide with steps to implement the mandatory data protection:
This is just one line in the article--it's meant to grab the readers attention.
The rest of the article provides real substance. Silly to claim the who article is nonsense based on one line.
The D&B numbers would be from the last fully reported year, i.e. 2016. They typically have pretty accurate data.
My point was not to imply this is a bad deal for any of the involved parties, but simply to add a data point to the discussion, one which other entrepreneurs looking for areas to add value should find highly interesting.
A quick D&B search on CoreOS, Inc. shows revenues of ~$550,000 [1], which means at $250m acquisition price, RH paid ~454X revenues..!
[1] http://www.hoovers.com/company-information/company-search.ht...