feat: support native social sign using apple sdk

[jonas-jonas]

This PR adds support for social sign in via Apple using an ID token instead of the browser based OIDC flows. This allows integration of the SDK for Apple sign in iOS.

How this works:

1. Use the Apple SDK on the device to request authentication, which returns an IDToken
2. Submit that token to Kratos using updateRegistrationFlow, alongside any traits you want the identity to have
3. Kratos verifies the token using Apple's public JWKS (make this configurable for the generic provider?)
4. Kratos extracts the data from the IDToken
5. Kratos processes the login/registration as if it came from an OIDC callback

Expo example (PR in repo following):

import * as AppleAuthentication from "expo-apple-authentication"
import * as Crypto from "expo-crypto"
import * as Random from "expo-random"

async function signInWithApple() {
  const nonce = Random.getRandomBytes(16).toString()

  const digest = await Crypto.digestStringAsync(
    Crypto.CryptoDigestAlgorithm.SHA256,
    nonce,
  )
  const credential = await AppleAuthentication.signInAsync({
    requestedScopes: [
      AppleAuthentication.AppleAuthenticationScope.EMAIL,
      AppleAuthentication.AppleAuthenticationScope.FULL_NAME,
    ],
    nonce: digest,
  })

  return orySdk.updateRegistrationFlow({
    flow: flow.id,
    updateRegistrationFlowBody: {
      provider: "apple",
      id_token: credential.identityToken,
      raw_id_token_nonce: nonce,
      traits: {
        name: {
          first: credential.fullName?.givenName || "given name", // When developing, these values might be empty
          last: credential.fullName?.familyName || "last name", // When developing, these values might be empty
        },
      },
    },
  })
}

Related issue(s)

Docs PR: ory/docs#1528

Checklist

• I have read the contributing guidelines.
• I have referenced an issue containing the design document if my change
  introduces a new feature.
• I am following the
  contributing code guidelines.
• I have read the security policy.
• I confirm that this pull request does not address a security
  vulnerability. If this pull request addresses a security vulnerability, I
  confirm that I got the approval (please contact
  [email protected]) from the maintainers to push
  the changes.
• I have added tests that prove my fix is effective or that my feature
  works.
• I have added or changed the documentation.

Further Comments

[codecov]

Codecov Report

Merging #3476 (fc30304) into master (fc30304) will not change coverage.
The diff coverage is n/a.

❗ Current head fc30304 differs from pull request most recent head b8de37b. Consider uploading reports for the commit b8de37b to get more accurate results

@@           Coverage Diff           @@
##           master    #3476   +/-   ##
=======================================
  Coverage   78.76%   78.76%           
=======================================
  Files         341      341           
  Lines       23707    23707           
=======================================
  Hits        18673    18673           
  Misses       3667     3667           
  Partials     1367     1367           

[jonas-jonas]

I am not sure, we can really e2e test this, as there is no other provider that supports verifying an ID Token from the payload, for now.

I guess, we could make the generic provider support it and add a JWKS URL to the config? Then we could obtain an ID token from a Hydra instance and submit that.

[aeneasr]

Looks very good, please add three tests to strategy_test:

• Test login with an ID token, ensure claims end up properly
• Test registration with an ID token, ensure claims end up properly
• Test login/registration with an ID token where the Client ID is not matching (should fail)
• Test login/registration with an ID token where the nonce is not matching (should fail)

Please also make it possible to submit the nonce and validate the nonce as well. Fail the flow if the nonce is not set.

[aeneasr]

The nonce implementation does not look correct to me. Typically, a nonce is a plain string (like the state parameter) and you do a string equality match to verify if it is valid or not. The nonce_supported flag defaults to false, which may be OK for apple, but is definitely not OK for any other provider, as this claim is not a standard claim (it is never mentioned here: https://openid.net/specs/openid-connect-core-1_0.html).

Additionally, the Apple documentation states:

A Boolean value that indicates whether the transaction is on a nonce-supported platform. If you send a nonce in the authorization request, but don’t see the nonce claim in the identity token, check this claim to determine how to proceed. If this claim returns true, treat nonce as mandatory and fail the transaction; otherwise, you can proceed treating the nonce as optional.

However, as far as I can see, we use this claim first to check whether we should validate. But the documentation states:

1. If a nonce was sent (aka if we receive the nonce as part of the registration / login payload
2. And the nonce is not available in the id_token
3. Then (and only then) we check this claim

The current implementation however:

1. Checks if the claim is true
2. Proceeds with validation

My suggestion is to move this custom validation logic into the apple ID token verification:

1. The apple provider validates the nonce claim:
2. If a nonce was sent as part of the payload
3. And the id_token has a nonce -> we validate
4. And the id_token has no nonce
   * We check the nonce_supported claim
   * If true: fail
   * If false: proceed
5. The Google provider also validates the nonce (but always, because Google returns this always)
6. The generic provider does not validate the nonce at all, it delegates the ID token validation to the specific provider (we can fix this later if desired).

Please don't merge this without another review from myself!

[aeneasr]

Much better! Almost there

[aeneasr]

Awesome!