6 ms·

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 peopl

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.
  - ElFitz 7y ago
    I wish there was an easy way to save a hackernews comment for later
    - floatingatoll 7y ago
      Click on the 'X minutes ago' permalink on the comment, and then select 'favorite'. It will show up under 'favorited ... comments' linked from your profile page while logged in.
      - ElFitz 7y ago
        Oh! Very nice! Thank you!
        floatingatoll 7y ago
        Favorites also works on stories (which you may already know).
      - eitland 7y ago
        More generally, and as hinted to by floatingatoll, the the 'X minutes ago' is also a permalink meaning after you click on it you can bookmark it in any bokmarking system you use. (I use pinboard.in) Also FWIE, going to the permalink for a comment also gives you access to the flag feature.
  - deathanatos 7y ago
    > There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds. I'm aware of OIDC's webfinger discovery mechanism; IIRC, it lets you translate "person@example.com" into a valid login. (But I don't think I've ever seen anyone implement this.) Is there something else? I think you could also implement just a DNS identifier to OIDC discovery which would let you translate something like "apple.com" into an OIDC flow, but you would need the provider to publish a OIDC discovery document, which Apple's implementation does not do. (Why, IDK, since that seems like a really easy thing to do. But Google — which does have one, technically — also isn't "google.com" or "gmail.com", so entering this seems a bit hard for a user to enter. (It's under "accounts.google.com"))
- vetinari 7y ago
  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.
- WorldMaker 7y ago
  `OpenID Connect` (OIDC) is not `OpenID`, despite the confusingly similar name. For the most part, `OpenID Connect` prefers to the wall full of Sign-In Options buttons/logos for determining ID Provider, instead of a user entering some specific address (as `OpenID` used to) and a lookup process, because there is more ceremony involved in establishing trust between an ID Provider and Relying Party as OIDC is built on top of OAuth APIs and generally you need an OAuth token or API key for your application (Relying Party) to initiate the API calls to login (even if those API calls themselves are standardized and can share a lot of library code by `OpenID Connect`). (You need a Facebook API key to enable "Sign in with Facebook" on your website, you need a Google API key to enable "Sign in with Google", and so forth.) So users are just trained to look for "Sign in with Apple" buttons, and websites get encouraged to add "Sign in with Apple" to their wall of sign-in options. Apple is going to make it a requirement for large categories of iOS apps in near future, so that will probably bubble out into website adoption in general.
  - dwaite 7y ago
    Yes, there is a way to do the dynamic functionality of OpenID 2.0 on Connect by using Metadata, WebFinger, and Dynamic Client Registration, but most of the large providers do not support all three of these. Google (for instance) wants a relying party to do some amount of registration/click through first in a web browser before their site can rely on Google. Apple (for their part) hangs your ability to support Sign in with Apple off of an app registration, which requires a developer or enterprise account and thus an annual fee.
    - WorldMaker 7y ago
      Yes, hence, "for the most part, prefers". Since it's an optional part of the spec and because basically no major OIDC IdP supports it nor plans to ever support it, it's basically nonexistent functionality.

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.
- ElFitz 7y ago
  I wish there was an easy way to save a hackernews comment for later
  - floatingatoll 7y ago
    Click on the 'X minutes ago' permalink on the comment, and then select 'favorite'. It will show up under 'favorited ... comments' linked from your profile page while logged in.
    - ElFitz 7y ago
      Oh! Very nice! Thank you!
      - floatingatoll 7y ago
        Favorites also works on stories (which you may already know).
    - eitland 7y ago
      More generally, and as hinted to by floatingatoll, the the 'X minutes ago' is also a permalink meaning after you click on it you can bookmark it in any bokmarking system you use. (I use pinboard.in) Also FWIE, going to the permalink for a comment also gives you access to the flag feature.
- deathanatos 7y ago
  > There are some discovery mechanisms that can be added for DNS/http(s) services as well against different tlds. I'm aware of OIDC's webfinger discovery mechanism; IIRC, it lets you translate "person@example.com" into a valid login. (But I don't think I've ever seen anyone implement this.) Is there something else? I think you could also implement just a DNS identifier to OIDC discovery which would let you translate something like "apple.com" into an OIDC flow, but you would need the provider to publish a OIDC discovery document, which Apple's implementation does not do. (Why, IDK, since that seems like a really easy thing to do. But Google — which does have one, technically — also isn't "google.com" or "gmail.com", so entering this seems a bit hard for a user to enter. (It's under "accounts.google.com"))
vetinari 7y ago
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.
WorldMaker 7y ago
`OpenID Connect` (OIDC) is not `OpenID`, despite the confusingly similar name. For the most part, `OpenID Connect` prefers to the wall full of Sign-In Options buttons/logos for determining ID Provider, instead of a user entering some specific address (as `OpenID` used to) and a lookup process, because there is more ceremony involved in establishing trust between an ID Provider and Relying Party as OIDC is built on top of OAuth APIs and generally you need an OAuth token or API key for your application (Relying Party) to initiate the API calls to login (even if those API calls themselves are standardized and can share a lot of library code by `OpenID Connect`). (You need a Facebook API key to enable "Sign in with Facebook" on your website, you need a Google API key to enable "Sign in with Google", and so forth.) So users are just trained to look for "Sign in with Apple" buttons, and websites get encouraged to add "Sign in with Apple" to their wall of sign-in options. Apple is going to make it a requirement for large categories of iOS apps in near future, so that will probably bubble out into website adoption in general.
- dwaite 7y ago
  Yes, there is a way to do the dynamic functionality of OpenID 2.0 on Connect by using Metadata, WebFinger, and Dynamic Client Registration, but most of the large providers do not support all three of these. Google (for instance) wants a relying party to do some amount of registration/click through first in a web browser before their site can rely on Google. Apple (for their part) hangs your ability to support Sign in with Apple off of an app registration, which requires a developer or enterprise account and thus an annual fee.
  - WorldMaker 7y ago
    Yes, hence, "for the most part, prefers". Since it's an optional part of the spec and because basically no major OIDC IdP supports it nor plans to ever support it, it's basically nonexistent functionality.