Sign in with Apple

The Sign in with Apple Authenticator uses an OpenID Connect like protocol to federate their user accounts and allow the user to select what information to share with the relying party. Some configuration in the Apple Developer portal is necessary.

Note

This authenticator requires an Apple Developer account to be able to configure a Sign in with Apple service.

Configuring a Sign in with Apple Service

To be able to use the Sign in with Apple feature, an App ID and a Service need to be added to your Apple developer account. To configure this, go to Apple Developer Portal.

Adding an App Identifier

In the menu option Certificates, Identifiers & Profiles, select Identifiers, and create a new identifier of the type App ID. This app is only needed to be used as the primary App ID in the Service identifier, if you already have one this step is unneccessary. If not, proceed to configure an App Identifier.

  • Choose the type App
../../_images/create-app-id-type.png
  • Add a description to the app, and create a unique bundle id.
../../_images/add-description-and-bundle-id.png
  • Enable Sign in with Apple
../../_images/app-id-enable-sign-in-with-apple.png
  • Press Continue and Register.

Create a new Service identifier

Now, create a new identifier of the type Services ID. In the setttings popup, add a description, and a create a unique identifier. Description will be visible for the end user while authenticating, and the identifier will be used in Curity config as the Client ID.

../../_images/create-services-id.png

Configuring Sign in with Apple

Go into your newly created service, and enable Sign in with Apple.

../../_images/enable-sign-in-with-apple.png

Select to configure the service. In the popup, select your App ID, and add the domain curity is running on, and add the redirect URI of your authenticator as the Return URL.

../../_images/configure-domain-and-redirect.png

Note

Your authenticator redirect URI can be found in the Admin UI, in the info pane of the authenticator configuration page. Since the authenticator is not created yet, the url follow the form of <base-url><authentication-endpoint>/<authenticator-id>/callback. This can be edited at a later stage, if you wish to change the authenticator id.

Press next and confirm your settings, and then save your Services ID Configuration.

Generating the private key

The Sign in with Apple service requires a private key that signs JWTs to be used as a client secret. The key to use is also generated in the developer portal. While still in the Certificates, Identifiers & Profiles page, select Keys.

  • Create a new Key with the following configuration:
../../_images/add-key.png
  • Select your App ID in the upcoming dialog.
../../_images/add-key-app-id.png
  • Save and register your key. In the finishing dialog, download your key, and make note of the genereated Key ID
../../_images/download-key.png

Note

If the key is lost after downloading, it is lost. But the Key ID can be retrieved from the developer portal at any time.

Now we are finished in the developer portal!

Setting up the authenticator

First we need to upload the key to use for client authentication. In the Admin UI, select Facilities -> Signing Keys -> +New In the popup, select the type asymetric and Upload Existing. Upload the downloaded key, without password and alias.

Now we’re ready to setup the authenticator. Go to Profiles –> <Authentication Profile> -> Authenticators. Create a new authenticator of the type Sign in with Apple.

In the authenticator, the following parameters are available:

Issuer: Should always be https://appleid.apple.com, unless another service is used for testing purposes. Apple does not have a test environment.

Team ID: Your Apple Team ID, can be found in the Apple Developer Portal <https://developer.apple.com/account>

Client ID: The identifier of your created service. For example: com.mygood.curity.integration

JWT Signing Key: Select the key that was uploaded in the previous step.

JWT Signing Key ID: This is the Key ID from the portal that we took note of earlier.

Scope: The scope to ask the end user to grant. This will affect the returned data. Default is openid email name, which will ask the user to share both the name and email. The user will get the chance to decide if it wants to share the real email or a relay email, and has the chance to not share the name.

HTTP Client: The http client to use in communication with the service. Select a client that is using https, and accepts the certificate of https://appleid.apple.com.

Example conf

<authenticator>
  <id>apple1</id>
  <sign-in-with-apple xmlns="https://curity.se/ns/conf/authenticators/appleid">
    <team-id>YKA7ZZCML0</team-id>
    <client-id>com.mygood.curity.integration</client-id>
    <jwt-signing-key>apple-signing-key</jwt-signing-key>
    <jwt-signing-key-id>U3P48554X4</jwt-signing-key-id>
  </sign-in-with-apple>
</authenticator>>

Returned data

The first time an end user chooses to sign in with apple, the user will get to select what data to share with the requesting application. Depending on what the user decides, the result will be a bit different. But the authentication attributes will contain an id for the subject, which will be persistent for this user but not readable. If the email scope was requested, the email attribute will be present, and if the name scope was asked for there will be a user attribute, which is a map that contain the name the user selected to share.

../../_images/authentication-result.png

Note that the user object will only be sent the first time this user authenticates. Next time, the subject will be the same, and the email will be only in the top level.