14 ms·

Apple Successfully Implements OpenID Connect with Sign in with Apple

534 points by atestu 7y ago

nathancahill 7y ago
This is really great. So many people were up in arms about Apple releasing an implementation that didn't comply with OpenID. Good on Apple for addressing the issues.
dfabulich 7y ago
Looks like Apple fixed all of the critical issues here https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md https://bitbucket.org/openid/connect/src/default/How-Sign-in... but left in some "peculiarities," some of which are quite unpleasant. > The scope value of only the very first request by an application is respected. If an application initially requests only the name scope, and the user allows it, it is then impossible to later also request the email scope. So if you don't ask for the user's email right up front, you can never ask for it again later?!
- jbigelow76 7y ago
  Yep, no "teaser" offers.
- orangepanda 7y ago
  How is that a bad thing?
  - scient 7y ago
    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 request everything right away, faced with a situation where they can't do it later.
    - floatingatoll 7y ago
      Can you offer a real-world example of when this would be the case for a product where logging in is required?
      - pcmaffey 7y ago
        You sign up for a product. No email is requested/provided. You might later want: - to submit a support request and receive a response via email. - to get blog posts or product updates in your email. - to receive a transaction receipt Trust is earned over time. I would much rather grant granular scopes as a product builds trust.
      - freehunter 7y ago
        Even from a user standpoint... oops I clicked the "cancel" button when I meant to click "confirm" and now I have to go through the signup process all over again because the developer is not allowed to ask me again.
        yreg 7y ago
        Last time I touched permissions the app was able to give the user a link to iOS Settings page where the user can grant previously denied permissions.
    - xvector 7y ago
      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.
      - enginaar 7y ago
        I believe the opposite is true. The apps will ask for information they don't need in case they'll need it later.
- bredren 7y ago
  Is there a straight-forward deauthorize / re-request ux loop to allow for changes to app scope over time?
wil421 7y ago
Thankfully. I do not use sign in with Google or Facebook and I would not feel comfortable signing in with any Ad company’s credentials.
sroussey 7y ago
Still not to spec. And no PKCE? Oy.
- evanriley 7y ago
  But it is to spec. [0] "Since September 2019 all spec violations have been addressed by Apple, as recorded in the next section. The section thereafter - "Peculiarities" lists specific implementation choices by Apple that differ from what most implementations provide, but are not spec violations per se." [0] - https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md https://bitbucket.org/openid/connect/src/default/How-Sign-in...
  - topspin 7y ago
    That list of "peculiarities" is pretty disappointing. The lack of a discovery endpoint is sad; it isn't that difficult to provide and it greatly reduces the obscurity of configuring RPs.
yoz-y 7y ago
This is maybe the first time I see a positive open letter. Kudos to both parties.
danpalmer 7y ago
I'm glad they've got the tech right for the actual authentication, but their email relay is still far from usable. It's limited in very fundamental ways, that will prevent many companies of any scale from using it. It's very difficult to make it work with an email service such as SendGrid, and it's limited to 10 domains you can prove ownership of, and 10 specific email addresses. I work for a company that charges users and ships physical products – our payment providers and shipping providers all need to be able to contact our customers if they choose to use those services, but this would be essentially impossible (or a prohibitive amount of technical work at scale). It's a very poor implementation. I wrote an obnoxiously long blog post about this. https://danpalmer.me/2019-07-02-on-signing-in-with-apple/ https://danpalmer.me/2019-07-02-on-signing-in-with-apple/
- floatingatoll 7y ago
  For context, the email relay policy from Apple, as mentioned above and quoted in the linked article under heading "Apple's "Email" Relay" is: https://help.apple.com/developer-account/#/devf822fb8fc https://help.apple.com/developer-account/#/devf822fb8fc In order to send email messages through the relay service to the users’ personal inboxes, you will need to register your outbound email domains. All registered domains must create Sender Policy Framework (SPF) DNS TXT records in order to transit Apple’s private mail relay. You can register up to 10 domains and communication emails.
- IfOnlyYouKnew 7y ago
  I've rarely seen vendors sharing e-mails with payment and shipping companies, and would consider it somewhat icky for privacy reasons, especially when done without the user's consent. It also seems that you could set up your own relay allowing those providers to contact your customers. In fact, that would be the privacy-conscious alternative even to your current implementation.
  - danpalmer 7y ago
    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 you for the purposes of fulfilling your request. This is all done under GDPR. The companies hold the data only for as long as they need, for the purposes explicitly requested by the user. This will all be included in privacy policies. > It also seems that you could set up your own relay allowing those providers to contact your customers. This might be technically possible, but introduces many concerns such as deliverability and spam ratings. Relaying email in this way is non-trivial when you're doing it at scale. For services sending ~100k emails a month or more, this requires careful planning because it's very easy to become filtered as spam.
heyoni 7y ago
Weren’t there some issues with their implementation of openid that the community was clamoring for Apple to fix? Did that ever happen? /edit instead of reading the article I went back to look for the old hn post :X somebody delete this, it’s embarrassing
- damvigilante 7y ago
  Yes, they've fixed the majority of them, that's what this update is about.
heyoni 7y ago
So they actually responded by fixing those issues? I wonder if they went as far delaying the release for that. If that’s the case, +1 to Apple for privacy
jsgo 7y ago
has sign in with Apple launched yet? It was the Big Thing in iOS 13 that I was personally most excited about but honestly, if it has launched, I haven't seen it yet. edit: from the comments it sounds like it has launched, but currently being implemented in a voluntary manner. Looked at the 9to5Mac article on iOS 13 support of apps and it looks like I just don't use any of them unfortunately. Love the idea still and hoping it gains heavily in adoption.
- rvanmil 7y ago
  Bird Rides[1] uses it. I tried it and it works very well. [1] https://www.bird.co https://www.bird.co
  - ilogik 7y ago
    the WWDC announcement said it would be mandatory starting in the spring. did that change?
    - ogre_codes 7y ago
      Mandatory so long as the app supports other third party authentication. If they exclusively use only their own accounts, it isn't required. (There are a couple other exceptions for business and education apps) Edit: https://developer.apple.com/news/?id=09122019b https://developer.apple.com/news/?id=09122019b New Apps will be required to implement this immediately, existing apps have until April next year to support it before updates will be rejected.
- mikhailt 7y ago
  Apps and services have to add this support in, it's not something Apple can do on their own. It is available as part of iOS 13, yes but it will take time.
- obenn 7y ago
  Just adding "Wordpress" and "Pocket Yoga" to this list. Wordpress is a good example of a service with a web implementation as well to try from the browser.
floatingatoll 7y ago
The working document linked to by this press release: https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md https://bitbucket.org/openid/connect/src/default/How-Sign-in... Since September 2019 all spec violations have been addressed by Apple, as recorded in the next section. The section thereafter - "Peculiarities" lists specific implementation choices by Apple that differ from what most implementations provide, but are not spec violations per se. The previous HN discussion about the spec violations: https://news.ycombinator.com/item?id=20311000 https://news.ycombinator.com/item?id=20311000
- jchw 7y ago
  And in fairness to Apple, most OIDC implementations have peculiarities. The Go OAuth library has a handful of quirks for specific providers.
djsumdog 7y ago
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 ID 1.0 concept, where you could use any identity provider with any service provider, is pretty much dead: https://battlepenguin.com/tech/the-decline-of-openid/ https://battlepenguin.com/tech/the-decline-of-openid/
- thefounder 7y ago
  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
  - floatingatoll 7y ago
    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 ...?
    - thefounder 7y ago
      Huh? Maybe you mean @icloud.com or @me.com. There is also a discovery/query mechanism that should tell you if x email is registered on a specific idp but I don't think Apple implemented it. Anyway there are various UI/UX solutions. Check gigya and related openID SaaS providers.
    - tracker1 7y ago
      Usually you offer a connect button with the most popular providers. You could also detect a login with somename@whateverapplemaildomain in order to passthrough for those addresses. There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds. In the end, probably would just add an apple-logo button next to twitter, google and facebook auth buttons. ---- Aside, in terms of data storage, separate the account, user and login/auth details. An account is related to activity inside the system. A user is a person authorized to use/act on or as that account. A login is an authority and related information to enter as a given user. Logins can be an OpenID reference, AD Integrated User, an API token, a local password entry (salted/hashed of course). If you make the separations above, you'll have far fewer issues if/when you need to make your application more flexible in terms of users/authentication against accounts. It also is very helpful when you will have "individual" accounts and "business entity" accounts, which may have variances in UI/UX. Beyond this, would separate the actual API/UI systems from auth systems relying on integrated tokens (like RSA signed JWT on an internal authority). In this way, your API systems only need to worry about "allowed" signers, and the roles assigned in the token's claims. Of course then there are issues with token lifetime, refresh and revocation to consider. Sorry for the blathering on this, literally working on an authentication management system (fairly barebones initially) right now. MVP at end of day after 4 months work.
atonse 7y ago
I wish Apple would actually publish the configuration document too (under the well-known URL, as listed in the peculiarities). It makes it one less step for OpenID clients to follow. I wonder what their rationale is, for not doing that (given how easy it is, compared to all the other things they fixed). But overall this is great news.
paul7986 7y ago
Say I have a web service with users but don't offer an email service with my core offering. Im guessing by using this I wouldn't be able to build iCloud Mail into my main service; allow my users to view, receive and send iCloud Mail through my web service?
baby 7y ago
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?
- icebraining 7y ago
  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.
- dwaite 7y ago
  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.
Confiks 7y ago
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 service provider, without the identity provider being able to see the transaction [3]. Multiple disclosures are also unlinkable as long as the attributes themselves are not identifying. The fact that the identity provider is not at all involved with the transaction is an enormous privacy win compared to OpenID Connect, especially in the case of centralizing providers such as Apple – and less so in for example the domain of education single sign-on. It's not currently using the verifiable claims data model, but it would very much fit it. It also doesn't use a 'blockchain', simply because it's not necessary to do so, and makes it all a lot less complicated. [1] https://github.com/privacybydesign https://github.com/privacybydesign [2] https://privacybydesign.foundation/publications/ https://privacybydesign.foundation/publications/ [3] https://privacybydesign.foundation/meeting-slides/slides-8-3-19/ringers-8-maart-2019.pdf#page=2&zoom=auto,-68,540 https://privacybydesign.foundation/meeting-slides/slides-8-3...
- icebraining 7y ago
  This sounds very similar to Mozilla's BrowserID. Is there any document contrasting the two?
  - floatingatoll 7y ago
    Any website could use BrowserID by including cross-domain JavaScript that sent cookies to a third party (browserid) and hand the session token over for auth and then get it back. This went poorly versus the modern web’s hostility to third-party cookies. For a website to use IRMA, it looks like they have to stand up a server component on their web server - it’s not enough to simply include Javascript like browserid, but it also isn’t subject to the third-party cookie failure of browserid.
- preommr 7y ago
  > Shameless plug (but I hope that's okay, again) I find lots of cool shit on hn because people decide to share their side projects that I wouldn't otherwise have seen. It only becomes a problem when people don't disclose they have a bias or connection to a product when they should.
madrox 7y ago
Slightly off topic, but it's been frustrating to me that large organizations only want to implement OpenID providers and not consumers. What Apple has done makes it easier to bring your Apple identity across the internet, but it's ultimately an identity that Apple owns.
- willow9886 7y ago
  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.
  - madrox 7y ago
    You are correct in that quite often who implements provider vs consumer depends largely on market position. There is technically no reason Apple can't become a consumer, other than they aren't interested in doing so. 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.
    - willow9886 7y ago
      > 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..!
willow9886 7y ago
For those of you interested in this topic, check out Internet Identity Workshop: https://internetidentityworkshop.com/ 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.
shujito 7y ago
sorry for this but this page is messing with the mouse scrolling, how can I prevent that? I've seen other several pages that do the same
antimora 7y ago
Apple's online credential/auth* user experience is terrible. I can't wait till Apple fixes their account auto-lock feature. On weekly basis I have to unlock my account because someone is trying to login with my email. I contacted the customer service to see if something could be done to avoid auto-locking. The only suggestion was to pick another email address that's not common. Also in order for me to unlock I have to supply my password along with answers to my 3 secret questions. Additionally my recovery email cannot be the same as my account email. Why Apple's online is terrible compared to their hardware/software?
- pojzon 7y ago
  To be honest I read all your complaints as a "screw Apple for protecting me".. pretty disrespectful. Their answer is expected. If your email is something like "john.smith@gmail.com" - there are like few hundred thousends of Smiths there.. And the complaint that recovery email cannot be the same as account email - so you want your account to be compromised without ANY way to recover it? Those seem like complaints of a completely "security oblivious" customer.
  - aaaaa 7y ago
    very interesting idea
  - freehunter 7y ago
    On the other hand, if a provider is saying "there is nothing we ca do to prevent a denial of service that's impacting your account", that's not a great response.
  - kps 7y ago
    The problem would go away if Apple got off their lazy lock-in ass and allowed U2F like everyone else.
  - antimora 7y ago
    I am talking about the basic user experience for my iTunes music, video and apps. Apple's "protection" of my account isn't better or stronger than other popular online services, such as, Facebook, Dropbox, or Gmail. I have more sensitive data in my Dropbox and Gmail accounts than Apple's. And yet I go through trouble each week to unlock my account. Why do I need to be troubled by it to get access to things I paid for? So here is a real story why I complained about requiring a different email address than the primary one. So a few years ago my apple account got locked due to their extra "protection". I tried to reset my password. I was given two options: to recovery by email or answer secret questions. Unfortunately I no longer had access to my works email and my answers weren't matching. It took another year till I could remember the exact answer I entered at the beginning. Till then my hundreds dollar of digital goods were locked out.
QuamStiver 7y ago
I just implemented this for an app, and was glad that for the most part Apple followed a standard here, but some of these “peculiarities” referenced are a PITA. Most notably imo: > The scope value of only the very first request by an application is respected. This means if you require an email address and something goes wrong before persisting it (e.g. the app crashes), there’s nothing you can do except ask the user to sign into their account on Apple’s website, revoke the app’s permissions, and start over.

534 points by atestu 7y ago

This is really great. So many people were up in arms about Apple releasing an implementation that didn't comply with OpenID. Good on Apple for addressing the issues.

dfabulich 7y ago

Looks like Apple fixed all of the critical issues here https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md https://bitbucket.org/openid/connect/src/default/How-Sign-in... but left in some "peculiarities," some of which are quite unpleasant. > The scope value of only the very first request by an application is respected. If an application initially requests only the name scope, and the user allows it, it is then impossible to later also request the email scope. So if you don't ask for the user's email right up front, you can never ask for it again later?!

jbigelow76 7y ago
Yep, no "teaser" offers.
orangepanda 7y ago
How is that a bad thing?
- scient 7y ago
  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 request everything right away, faced with a situation where they can't do it later.
  - floatingatoll 7y ago
    Can you offer a real-world example of when this would be the case for a product where logging in is required?
    - pcmaffey 7y ago
      You sign up for a product. No email is requested/provided. You might later want: - to submit a support request and receive a response via email. - to get blog posts or product updates in your email. - to receive a transaction receipt Trust is earned over time. I would much rather grant granular scopes as a product builds trust.
    - freehunter 7y ago
      Even from a user standpoint... oops I clicked the "cancel" button when I meant to click "confirm" and now I have to go through the signup process all over again because the developer is not allowed to ask me again.
      - yreg 7y ago
        Last time I touched permissions the app was able to give the user a link to iOS Settings page where the user can grant previously denied permissions.
  - xvector 7y ago
    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.
    - enginaar 7y ago
      I believe the opposite is true. The apps will ask for information they don't need in case they'll need it later.
bredren 7y ago
Is there a straight-forward deauthorize / re-request ux loop to allow for changes to app scope over time?

wil421 7y ago

Thankfully. I do not use sign in with Google or Facebook and I would not feel comfortable signing in with any Ad company’s credentials.

sroussey 7y ago

Still not to spec. And no PKCE? Oy.

evanriley 7y ago
But it is to spec. [0] "Since September 2019 all spec violations have been addressed by Apple, as recorded in the next section. The section thereafter - "Peculiarities" lists specific implementation choices by Apple that differ from what most implementations provide, but are not spec violations per se." [0] - https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md https://bitbucket.org/openid/connect/src/default/How-Sign-in...
- topspin 7y ago
  That list of "peculiarities" is pretty disappointing. The lack of a discovery endpoint is sad; it isn't that difficult to provide and it greatly reduces the obscurity of configuring RPs.

yoz-y 7y ago

This is maybe the first time I see a positive open letter. Kudos to both parties.

danpalmer 7y ago

I'm glad they've got the tech right for the actual authentication, but their email relay is still far from usable. It's limited in very fundamental ways, that will prevent many companies of any scale from using it. It's very difficult to make it work with an email service such as SendGrid, and it's limited to 10 domains you can prove ownership of, and 10 specific email addresses. I work for a company that charges users and ships physical products – our payment providers and shipping providers all need to be able to contact our customers if they choose to use those services, but this would be essentially impossible (or a prohibitive amount of technical work at scale). It's a very poor implementation. I wrote an obnoxiously long blog post about this. https://danpalmer.me/2019-07-02-on-signing-in-with-apple/ https://danpalmer.me/2019-07-02-on-signing-in-with-apple/

floatingatoll 7y ago
For context, the email relay policy from Apple, as mentioned above and quoted in the linked article under heading "Apple's "Email" Relay" is: https://help.apple.com/developer-account/#/devf822fb8fc https://help.apple.com/developer-account/#/devf822fb8fc In order to send email messages through the relay service to the users’ personal inboxes, you will need to register your outbound email domains. All registered domains must create Sender Policy Framework (SPF) DNS TXT records in order to transit Apple’s private mail relay. You can register up to 10 domains and communication emails.
IfOnlyYouKnew 7y ago
I've rarely seen vendors sharing e-mails with payment and shipping companies, and would consider it somewhat icky for privacy reasons, especially when done without the user's consent. It also seems that you could set up your own relay allowing those providers to contact your customers. In fact, that would be the privacy-conscious alternative even to your current implementation.
- danpalmer 7y ago
  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 you for the purposes of fulfilling your request. This is all done under GDPR. The companies hold the data only for as long as they need, for the purposes explicitly requested by the user. This will all be included in privacy policies. > It also seems that you could set up your own relay allowing those providers to contact your customers. This might be technically possible, but introduces many concerns such as deliverability and spam ratings. Relaying email in this way is non-trivial when you're doing it at scale. For services sending ~100k emails a month or more, this requires careful planning because it's very easy to become filtered as spam.

heyoni 7y ago

Weren’t there some issues with their implementation of openid that the community was clamoring for Apple to fix? Did that ever happen? /edit instead of reading the article I went back to look for the old hn post :X somebody delete this, it’s embarrassing

damvigilante 7y ago
Yes, they've fixed the majority of them, that's what this update is about.

heyoni 7y ago

So they actually responded by fixing those issues? I wonder if they went as far delaying the release for that. If that’s the case, +1 to Apple for privacy

jsgo 7y ago

has sign in with Apple launched yet? It was the Big Thing in iOS 13 that I was personally most excited about but honestly, if it has launched, I haven't seen it yet. edit: from the comments it sounds like it has launched, but currently being implemented in a voluntary manner. Looked at the 9to5Mac article on iOS 13 support of apps and it looks like I just don't use any of them unfortunately. Love the idea still and hoping it gains heavily in adoption.

rvanmil 7y ago
Bird Rides[1] uses it. I tried it and it works very well. [1] https://www.bird.co https://www.bird.co
- ilogik 7y ago
  the WWDC announcement said it would be mandatory starting in the spring. did that change?
  - ogre_codes 7y ago
    Mandatory so long as the app supports other third party authentication. If they exclusively use only their own accounts, it isn't required. (There are a couple other exceptions for business and education apps) Edit: https://developer.apple.com/news/?id=09122019b https://developer.apple.com/news/?id=09122019b New Apps will be required to implement this immediately, existing apps have until April next year to support it before updates will be rejected.
mikhailt 7y ago
Apps and services have to add this support in, it's not something Apple can do on their own. It is available as part of iOS 13, yes but it will take time.
obenn 7y ago
Just adding "Wordpress" and "Pocket Yoga" to this list. Wordpress is a good example of a service with a web implementation as well to try from the browser.

floatingatoll 7y ago

The working document linked to by this press release: https://bitbucket.org/openid/connect/src/default/How-Sign-in-with-Apple-differs-from-OpenID-Connect.md https://bitbucket.org/openid/connect/src/default/How-Sign-in... Since September 2019 all spec violations have been addressed by Apple, as recorded in the next section. The section thereafter - "Peculiarities" lists specific implementation choices by Apple that differ from what most implementations provide, but are not spec violations per se. The previous HN discussion about the spec violations: https://news.ycombinator.com/item?id=20311000 https://news.ycombinator.com/item?id=20311000

jchw 7y ago
And in fairness to Apple, most OIDC implementations have peculiarities. The Go OAuth library has a handful of quirks for specific providers.

djsumdog 7y ago

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 ID 1.0 concept, where you could use any identity provider with any service provider, is pretty much dead: https://battlepenguin.com/tech/the-decline-of-openid/ https://battlepenguin.com/tech/the-decline-of-openid/

thefounder 7y ago
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
- floatingatoll 7y ago
  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 ...?
  - thefounder 7y ago
    Huh? Maybe you mean @icloud.com or @me.com. There is also a discovery/query mechanism that should tell you if x email is registered on a specific idp but I don't think Apple implemented it. Anyway there are various UI/UX solutions. Check gigya and related openID SaaS providers.
  - tracker1 7y ago
    Usually you offer a connect button with the most popular providers. You could also detect a login with somename@whateverapplemaildomain in order to passthrough for those addresses. There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds. In the end, probably would just add an apple-logo button next to twitter, google and facebook auth buttons. ---- Aside, in terms of data storage, separate the account, user and login/auth details. An account is related to activity inside the system. A user is a person authorized to use/act on or as that account. A login is an authority and related information to enter as a given user. Logins can be an OpenID reference, AD Integrated User, an API token, a local password entry (salted/hashed of course). If you make the separations above, you'll have far fewer issues if/when you need to make your application more flexible in terms of users/authentication against accounts. It also is very helpful when you will have "individual" accounts and "business entity" accounts, which may have variances in UI/UX. Beyond this, would separate the actual API/UI systems from auth systems relying on integrated tokens (like RSA signed JWT on an internal authority). In this way, your API systems only need to worry about "allowed" signers, and the roles assigned in the token's claims. Of course then there are issues with token lifetime, refresh and revocation to consider. Sorry for the blathering on this, literally working on an authentication management system (fairly barebones initially) right now. MVP at end of day after 4 months work.

atonse 7y ago

I wish Apple would actually publish the configuration document too (under the well-known URL, as listed in the peculiarities). It makes it one less step for OpenID clients to follow. I wonder what their rationale is, for not doing that (given how easy it is, compared to all the other things they fixed). But overall this is great news.

paul7986 7y ago

Say I have a web service with users but don't offer an email service with my core offering. Im guessing by using this I wouldn't be able to build iCloud Mail into my main service; allow my users to view, receive and send iCloud Mail through my web service?

baby 7y ago

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?

icebraining 7y ago
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.
dwaite 7y ago
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.

Confiks 7y ago

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 service provider, without the identity provider being able to see the transaction [3]. Multiple disclosures are also unlinkable as long as the attributes themselves are not identifying. The fact that the identity provider is not at all involved with the transaction is an enormous privacy win compared to OpenID Connect, especially in the case of centralizing providers such as Apple – and less so in for example the domain of education single sign-on. It's not currently using the verifiable claims data model, but it would very much fit it. It also doesn't use a 'blockchain', simply because it's not necessary to do so, and makes it all a lot less complicated. [1] https://github.com/privacybydesign https://github.com/privacybydesign [2] https://privacybydesign.foundation/publications/ https://privacybydesign.foundation/publications/ [3] https://privacybydesign.foundation/meeting-slides/slides-8-3-19/ringers-8-maart-2019.pdf#page=2&zoom=auto,-68,540 https://privacybydesign.foundation/meeting-slides/slides-8-3...

icebraining 7y ago
This sounds very similar to Mozilla's BrowserID. Is there any document contrasting the two?
- floatingatoll 7y ago
  Any website could use BrowserID by including cross-domain JavaScript that sent cookies to a third party (browserid) and hand the session token over for auth and then get it back. This went poorly versus the modern web’s hostility to third-party cookies. For a website to use IRMA, it looks like they have to stand up a server component on their web server - it’s not enough to simply include Javascript like browserid, but it also isn’t subject to the third-party cookie failure of browserid.
preommr 7y ago
> Shameless plug (but I hope that's okay, again) I find lots of cool shit on hn because people decide to share their side projects that I wouldn't otherwise have seen. It only becomes a problem when people don't disclose they have a bias or connection to a product when they should.

madrox 7y ago

Slightly off topic, but it's been frustrating to me that large organizations only want to implement OpenID providers and not consumers. What Apple has done makes it easier to bring your Apple identity across the internet, but it's ultimately an identity that Apple owns.

willow9886 7y ago
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.
- madrox 7y ago
  You are correct in that quite often who implements provider vs consumer depends largely on market position. There is technically no reason Apple can't become a consumer, other than they aren't interested in doing so. 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.
  - willow9886 7y ago
    > 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..!

willow9886 7y ago

For those of you interested in this topic, check out Internet Identity Workshop: https://internetidentityworkshop.com/ 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.

shujito 7y ago

sorry for this but this page is messing with the mouse scrolling, how can I prevent that? I've seen other several pages that do the same

antimora 7y ago

Apple's online credential/auth* user experience is terrible. I can't wait till Apple fixes their account auto-lock feature. On weekly basis I have to unlock my account because someone is trying to login with my email. I contacted the customer service to see if something could be done to avoid auto-locking. The only suggestion was to pick another email address that's not common. Also in order for me to unlock I have to supply my password along with answers to my 3 secret questions. Additionally my recovery email cannot be the same as my account email. Why Apple's online is terrible compared to their hardware/software?

pojzon 7y ago
To be honest I read all your complaints as a "screw Apple for protecting me".. pretty disrespectful. Their answer is expected. If your email is something like "john.smith@gmail.com" - there are like few hundred thousends of Smiths there.. And the complaint that recovery email cannot be the same as account email - so you want your account to be compromised without ANY way to recover it? Those seem like complaints of a completely "security oblivious" customer.
- aaaaa 7y ago
  very interesting idea
- freehunter 7y ago
  On the other hand, if a provider is saying "there is nothing we ca do to prevent a denial of service that's impacting your account", that's not a great response.
- kps 7y ago
  The problem would go away if Apple got off their lazy lock-in ass and allowed U2F like everyone else.
- antimora 7y ago
  I am talking about the basic user experience for my iTunes music, video and apps. Apple's "protection" of my account isn't better or stronger than other popular online services, such as, Facebook, Dropbox, or Gmail. I have more sensitive data in my Dropbox and Gmail accounts than Apple's. And yet I go through trouble each week to unlock my account. Why do I need to be troubled by it to get access to things I paid for? So here is a real story why I complained about requiring a different email address than the primary one. So a few years ago my apple account got locked due to their extra "protection". I tried to reset my password. I was given two options: to recovery by email or answer secret questions. Unfortunately I no longer had access to my works email and my answers weren't matching. It took another year till I could remember the exact answer I entered at the beginning. Till then my hundreds dollar of digital goods were locked out.

QuamStiver 7y ago

I just implemented this for an app, and was glad that for the most part Apple followed a standard here, but some of these “peculiarities” referenced are a PITA. Most notably imo: > The scope value of only the very first request by an application is respected. This means if you require an email address and something goes wrong before persisting it (e.g. the app crashes), there’s nothing you can do except ask the user to sign into their account on Apple’s website, revoke the app’s permissions, and start over.