Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple Successfully Implements OpenID Connect with Sign in with Apple

openid.net

Post reply on HN
Print view View original

41–50 of 121 posts

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

#41

Post by vokep »

sdegutis wrote: post #29
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…

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.

Its a mix, fully centralized takes power away from people and sucks. Fully decentralized is not stable enough to survive as something useful. The trick is finding the right balance between. Generally its safe to bias towards decentralization because so much historically has overly tended towards centralization.

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

#42

Post by floatingatoll »

danpalmer wrote: post #40

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 use…

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

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.

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

#43

Post by IfOnlyYouKnew »

danpalmer wrote: post #40

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 use…

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.

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

#44

Post by atonse »

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.

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

#45

Post by topspin »

evanriley wrote: post #36
sroussey wrote: post #30

Still not to spec. And no PKCE? Oy.

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...

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.

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

#46

Post by floatingatoll »

thefounder wrote: post #16
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…

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 ...?

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

#47

Post by floatingatoll »

scient wrote: post #35
orangepanda wrote: post #32

Earlier quoted context omitted.

How is that a bad thing?

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…

Can you offer a real-world example of when this would be the case for a product where logging in is required?

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

#48

Post by paul7986 »

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?

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

#49

Post by lucasverra »

jsgo wrote: post #5

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 h…

web démo here https://starter-siwa.glitch.me/ (not mine)

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

#50

Post by xvector »

scient wrote: post #35
orangepanda wrote: post #32

Earlier quoted context omitted.

How is that a bad thing?

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.

Post reply on HN