Apple Successfully Implements OpenID Connect with Sign in with Apple • Hacker News Board

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#61

Post by vetinari » Thu, Oct 03, 2019, 8:34 PM UTC

floatingatoll wrote: post #46

thefounder wrote: post #16

Earlier quoted context omitted.

You can allow people with apple accounts to login into your website without to write Apple specific code. Just use whatever lib you've been using to allow people to auth with their Google accounts or any other 3rd party openid connect idp

What value would they enter at what prompt in order to activate the Apple Accounts process? For example, "openid.apple.com" or "some_email_address@openid.apple.com" or ...?

It is usually button "Sign in with...". In your app, each identity provider has to be configured (and your app has to be enrolled with the identity provider). Similar, as with Google, Github, etc.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#62

Post by tracker1 » Thu, Oct 03, 2019, 8:36 PM UTC

azinman2 wrote: post #38

sdegutis wrote: post #29

Earlier quoted context omitted.

Decentralization always fails, centralization is inherent to society and human nature. That's why we generally centralize around areas that turn into huge metropolitan cities, and why 99% of git usage is on Github, Gitlab or Bitbucket. We're a centralization-loving race. So OAuth 1.0's dream of decentralization resulted in only a few OAuth providers ever lasting long.

Except that TCP/IP, email, and the web has shown that it can also be otherwise. Big sites come and go. I don’t think you can always state general rules along these lines (cities are different from hosting source code). You have to look at the friction vs advantages per scenario. The web, for example, has little friction due to Google providing the grease, and massive long-tail advantages in decentralization. OpenID h…

On the last point... in general, a lot of sites, in order to let users participate only really care about having a name and email address or phone for contact needs. Most don't really even care about that. Why not let any number of other systems take care of that. For that matter, they also handle validation.

I'd rather let FB/Google/Twitter and now Apple deal with verification details, and let them participate in a site. It also means, on doesn't have to deal with persisting or dealing with passwords (that can be breached) etc.

Of course, I'm still inclined to allow local/passworded accounts and ensure salt+hashing of passphrases, etc. It's just in a lot of ways much easier as a user.

Depending on the site, I'd often prefer Twitter (until my short account ban/lock, which made life more difficult for a few days... FYI, don't rile up the communists too much).

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#63

Post by tracker1 » Thu, Oct 03, 2019, 8:36 PM UTC

slezyr wrote: post #56

sdegutis wrote: post #29

Earlier quoted context omitted.

Decentralization always fails, centralization is inherent to society and human nature. That's why we generally centralize around areas that turn into huge metropolitan cities, and why 99% of git usage is on Github, Gitlab or Bitbucket. We're a centralization-loving race. So OAuth 1.0's dream of decentralization resulted in only a few OAuth providers ever lasting long.

Do you have a second to talk about real p2p - bittorrent? It doesn't fits in your believe at all.

The biggest issue with bittorrent is discovery channels and search.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#64

Post by icebraining » Thu, Oct 03, 2019, 8:37 PM UTC

Confiks wrote: post #57

Shameless plug (but I hope that's okay, again): IRMA Authentication is an open-source app [1] and protocol that offers privacy-friendly attribute based authentication and signing using Camenisch and Lysyanskaya's Idemix [2]. It's currently heavily focused towards The Netherlands, where citizens can obtain attributes such as name, home address and age. These attributes can then be selectively disclosed directly to a s…

This sounds very similar to Mozilla's BrowserID. Is there any document contrasting the two?

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#65

Post by spookthesunset » Thu, Oct 03, 2019, 8:38 PM UTC

ryandrake wrote: post #60

danpalmer wrote: post #51

Earlier quoted context omitted.

Many delivery providers need to be able to contact the person they are delivering to. This is standard practice. The same is true for many non-trivial payment providers (such as PayPal/Klarna). This data is shared for the legitimate interests of the customer. You've bought something and asked to a) pay for it, and b) have it delivered. I think it's reasonable to expect that the companies involved in this can contact…

What stops the user from consensually providing this information in a form field at checkout, if they wish for such contact?

1. You already gave those downstream vendors your contact information so they can, you know, ship your package to your home and charge your credit card.

2. 99.99% of all users probably want to be emailed tracking information or payment confirmation information. Adding such a checkbox only adds friction to their funnel in order to please an incredibly small minority of people using their site.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#66

Post by enginaar » Thu, Oct 03, 2019, 8:51 PM UTC

xvector wrote: post #50

scient wrote: post #35

Earlier quoted context omitted.

How is it not? Consent to releasing information should be supported on a granular on-demand level. If I initially only need name, I'll ask the user to consent for that. If I later on need an email (lets say for some additional functionality user is trying to access), I'll ask for email separately. This is much better than being constrained to only the initial scope being respected, resulting everyone basically reques…

I think it is great. I have seen so many dark patterns where apps request more and more things they shouldn't need. This way everything the app will need is up-front.

I believe the opposite is true. The apps will ask for information they don't need in case they'll need it later.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#67

Post by dwaite » Thu, Oct 03, 2019, 8:55 PM UTC

djsumdog wrote: post #8

So I don't currently use Apple products, does this mean that people can use their own OpenID Connect identity providers with Apple (like if I run an Open ID Connect server at idp.example.com, I can add it as an authentication source) or is this just for using Apple's Identity Provider to allow your own apps to log-in via your Apple account? Open ID Connect is essentially a an OAuth2 implementation. The original Open…

> So I don't currently use Apple products, does this mean that people can use their own OpenID Connect identity providers with Apple ... or is this just for using Apple's Identity Provider to allow your own apps to log-in via your Apple account?

The latter - like other IDPs that support OIDC, an website can now use Apple for authentication with the same libraries as they use for Google, Microsoft, etc.

> Open ID Connect is essentially a an OAuth2 implementation.

OpenID Connect is an OAuth2 profile.

> The original Open ID 1.0 concept, where you could use any identity provider with any service provider, is pretty much dead.

The functionality is there, but is optional. As a result, it is seldomly used.

OpenID 1.0 supported using arbitrary OPs, but there was no actual organizational trust there:

- if the OP and RP had an interoperability issue, the first time it would be seen would be with an end-user. In many cases, the only way the OP/RP would know there was an issue would be when the end-user reported it. - if the OP messed up authentication and let the wrong person in, the RP had no recourse. - if the OP went away, you could very well have no alternative mechanism to recover the user account on the RP side - neither side necessarily took responsibility for the user education of how a URL ("what is a Earl?") could be used for authentication

Even in its heyday, there were 10x more OpenID 2.0 OPs than RPs because of these challenges. In my opinion, it was more that the very concept was not ready for the market. That is why with OpenID Connect, most parties have not deployed this sort of user-centric Bring-your-own-OP approach even though it is a capability of the profile.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#68

Post by Operyl » Thu, Oct 03, 2019, 8:57 PM UTC

ogre_codes wrote: post #19

Gaelan wrote: post #10

Earlier quoted context omitted.

Apple was planning on making SIWA support mandatory, but pushed that back to 2020.

For new Apps it is mandatory, existing apps have until April of next year to support it before updates will start getting rejected.

Only mandatory if you use Facebook/google sign in.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#69

Post by icebraining » Thu, Oct 03, 2019, 9:03 PM UTC

baby wrote: post #54

Can someone explain who is OpenID, what's the OpenID Connect Self Certification Test Suite, and why it is so important that Apple follows their spec?

OpenID Connect is a protocol for any site (and other software) to ask an identity provider who the user accessing the site is. Generally the user chooses one provider among those supported by the site (e.g. Google, Facebook, etc) and gets redirected to it, so it can authorize the authentication, then gets sent back to the site, and the site can now get info about them (usually some ID, and an email address).

This allows the site/user to avoid having to provide and store a password, since the site can just create an account and login the user based on the ID given by the provider.

Apple started using that protocol, allowing sites to authenticate users with them, but it broke a few parts of the standard, which meant the site developers couldn't use their normal libraries to connect to Apple's identity provider.

Re: Apple Successfully Implements OpenID Connect with Sign in with Apple

#70

Post by dwaite » Thu, Oct 03, 2019, 9:06 PM UTC

baby wrote: post #54

Can someone explain who is OpenID, what's the OpenID Connect Self Certification Test Suite, and why it is so important that Apple follows their spec?

OpenID Connect is a profile of OAuth 2 that adds authentication and identity information. Sign in with Apple was a partial implementation of OpenID Connect, for sharing authentication as well as an email address and the user's name between Apple and other apps/services.

As a partial implementation, there were both difficulties using existing third party libraries and known security issues in Apple's implementation. This was shown initially by manual inspection, then by Apple's implementation failing the freely available certification test suite published by the OpenID Foundation (I believe run by third parties, not Apple themselves).

The OpenID Foundation published an open letter both to ask Apple to fix these issues, and to inform other operators that there were security issues with Apple's implementation.

A complete implementation solves known security and interoperability issues.