Sign in with Apple

Will Sign in with Apple be a supported sign in method when it reaches public availability later this year?

12 Likes

Nobody’s been assigned to it yet but I suspect it’ll happen if they gain traction. Even if we don’t do it quickly in discourse core I think it’s likely someone in the community will create a plugin.

7 Likes

Cool. I hadn’t seen it mentioned anywhere yet, so thought I’d bring it up!

I could have a crack at this, given I just PR’d to the Discord one … how hard can it be? :wink:

I also feel it’s important to support identity management with a company that is more privacy focussed that, ahem, others we could mention.

11 Likes

Do it @merefield!

As there is a omniauth-apple strategy already it should be doable GitHub - nhosoya/omniauth-apple: OmniAuth strategy for Sign In with Apple

14 Likes

Very useful, thanks Rafael

Very close wtih this now, but have encountered a snag:

The OAuth strategy requires a pem key file (which you get from those kind people at Apple)

When I attempt to store this in a SiteSetting, the text is somehow corrupted and generation of the private key fails:

::OpenSSL::PKey::EC.new(options.pem)

# OpenSSL::PKey::ECError

## invalid curve name

I’ve attempted to escape the text with \n's where there are new lines.

I can’t see how this can be deployable unless we can somehow store the contents of this file in a SiteSetting?

1 Like

The .pem is just the public key, isn’t it?

In this case it includes the private key (apparently there are other things encoded in it).

The code goes on to use this private key to generate the client secret.

I’ve tested the library with the pem file and it’s valid, but as soon as you paste the file into a SiteSetting it (perhaps predictably) get’s subtly altered.

UPDATE: looks like \n is replaced with \\n in SiteSettings, so may be able to search for \\ on retrieve and cut it down by one

Seems like I was able to deal, sorry for the spam.

6 Likes

An update:

My plugin appears to be working up to a point, however, I’m currently getting a vague error from Apple when attempting to authenticate with the credentials I’ve set up as an Apple Developer:

“Your request could not be completed because of an error. Please try again later”

As you might imagine, this doesn’t give me a lot to go on.

This is compounded slightly because their authorization scheme is a lot different to the OAuth 2.0 standard.

Unfortunately I’m not able to raise a full TSI ticket with Apple yet because the feature is pre-release, but I will submit a Feedback Issue.

The repo is here:

NB Use at your own risk - not yet successfully tested!

6 Likes

Maybe we use a file upload for the pem file? How large is it?

It’s tiny :slight_smile:

PEM ‘file’ (as a string in Site Setttings) seems to be processed fine, so that doesn’t seem to be the issue any longer.

That original error has gone away. JWT seems to process it fine now.

I solved it by replacing the new lines with a $ sign, and then replacing the $ sign with a new line when passing it to the JWT function. Non-standard, but works. Supplying ‘/’ messes things up because of the way Ruby handles it. (I admit however, though no exception is raised, this could still be a problem area)

You are more than welcome to use your Apple credentials and give it a go.

I fear I’ve got something wrong with the credentials.

You need to provide:

  • Team ID
  • Client ID
  • PEM
  • Key ID

It’s very fiddly to set this all up on Apple’s website :slight_smile:

7 Likes

@merefield I have it successfully running on sandbox.dtaylor.uk :tada:

I had to make a couple of changes in our fork to allow for domain verification. I also added some more specific descriptions to the site settings, and enabled multi-line support for the PEM.

It looks like the omniauth-apple gem does not (yet?) support passing any information about the user… which is not particularly useful for us. It looks like sign-in-with-apple is almost OpenID-Connect compatible, so it’s possible we might be able to re-use some of the functionality from that plugin.

In terms of setting up the credentials, I found this (very appropriately named) blog post far more useful than Apple’s documentation:

10 Likes

That’s great! Ah textarea is new to me. That avoids my ‘hack’ I added nicely. Perfect! If only I had known about that! :sweat_smile:

I like the txt file verification check you added, nice touch. I had done that manually, but that’s a great assistance for deployed use.

Yes I used that too.

Sadly I’m still getting the same Apple-side error after merging your fork, so I suspect I’m still doing something silly with credentials. I may PM you if I may to swap notes! :wink:

6 Likes

OK, turned out my problem was almost certainly trying to access with a partially dev site (running with nginx and over https though).

I retried with a Production site and :tada:

but unfortunately, as you say, “Name” is not returned and this must be the middleware, right? As looks like Apple letting you authorise this.

Are we sure that it will return a name? From a privacy perspective it’s almost better if the user picks a name than have any public PII disclosed in the process.

It should do technically? But agree with your point, though you can choose not to expose it at the Apple page. Moot, as it turns out so far!

Yes, someone had raised an issue about this, but it was then closed.

I’ve commented on it

I’m guessing this is the area of code we’re concerned about?:

      info do
        { sub: id_token['sub'] }
      end

whereas in the discord auth gem, for example, we get this:

      info do
        {
          name: raw_info['username'],
          email: raw_info['verified'] ? raw_info['email'] : nil,
          image: "https://cdn.discordapp.com/avatars/#{raw_info['id']}/#{raw_info['avatar']}"
        }
      end

FYI No mention of those fields in Apple’s API documentation …

https://developer.apple.com/documentation/signinwithapplerestapi/tokenresponse

It looks like this PR adds the useful user information: Use JWT gem and some refactor by fjaeger · Pull Request #7 · nhosoya/omniauth-apple · GitHub. Hopefully it will be merged soon, or if not we could look at using a fork

4 Likes

Yes, you are right, I’d seen that PR but not dug into the code and thought it was simply switching to a different dependency. People should consider not PR-ing with such huge scope as details like that can be lost.

As you said:

        {
          sub: id_info['sub'],
          email: user_info.dig('email'),
          first_name: user_info.dig('name', 'firstName'),
          last_name: user_info.dig('name', 'lastName'),
          extra: {
            raw_info: id_info.merge(user_info)
          }
        } 

I’ve added a comment to support the PR.

3 Likes