Hello,
I started to see this error in production:

gems/apple_id-1.1.1/lib/apple_id/id_token/real_user_status.rb:24:in `status': no implicit conversion of String into Integer (TypeError)

It happens when Apple's JWT contains real_user_status field.

I've managed to track it down to this line in gem openid_connect:
https://github.com/nov/openid_connect/blob/a76c9c84458a0d8c3ec3783ec6c815c285c05d91/lib/openid_connect/response_object/id_token.rb#L19

What happens here is all claims unspecified by OpenID Connect protocol are converted into strings, so a raw attribute value of real_user_status: 0 becomes real_user_status: "0", and blows up with error mentioned.

Is this conversion into strings mandated by OpenID Connect?
If yes, I'm happy to provide a PR that undoes it here in apple_id.
Alternatively, I could post a PR into openid_connect gem.

What would you prefer?

I guess you need to provide a response :)

The instructions for sending an authorisation request dont work because the url must have &response_mode=form_post. Without it, Apple errors out with:

response_mode must be form_post when name or email scope is requested

See https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_js/incorporating_sign_in_with_apple_into_other_platforms

If you requested any scopes, the value must be form_post.

After installing the applie_id gem, I ran my test suite and noticed many failures around email validation.

Error:
EmailValidatorTest#test_: EmailValidator should not allow :email to be ‹"foo@abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.abc.com"›. :
NoMethodError: undefined method `negative_failure_message' for #<Shoulda::Matchers::ActiveModel::AllowValueMatcher:0x00007fdf70118080>
    -e:1:in `<main>'

bin/rails test ~/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/shoulda-context-1.2.2/lib/shoulda/context/context.rb:360

After inspecting the Gemfile.lock, I noticed this dependency hierarchy:

apple_id (0.3.0) 
  openid_connect (~> 1.1.7)
    validate_email

I took a look at the validate_email gem repo, and it looks to me like this gem takes the liberty of defining an ActiveModel::EachValidator. This means that any model in my application that has declared the following validation:

validates :email, email: true

Will now use the EmailValidator defined by the validate_email gem instead of the one we have declared in our own codebase, which happens to have the same name.

The validate_email gem also appears to have been a shim for Rails 3 when (perhaps) this sort of validation did not come out of the box? untrue, rails still does not have email validation out of the box.

Request:

Can we remove this dependency from the openid_connect connect gem and default to using standard active model validations? Otherwise this will unfortunately not allow me to take advantage of this very useful gem. no longer the right solution . Please read comment below.

I'm getting a weird invalid_client error trying to implement Sign in with Apple using this gem.

It is always failing on this line:

token_response = @client.access_token!

12:07:12 web.1  | #<AppleID::Client:0x00000001100a4518 @identifier="app.prayerteam.web", @team_id="FL726TVN3W.app.prayerteam", @key_id="YG33TJYKQ7", @private_key=#<OpenSSL::PKey::EC:0x00000001100a46f8 oid=id-ecPublicKey>, @secret=nil, @certificate=nil, @redirect_uri="https://exactly-holy-sunbird.ngrok-free.app/users/auth/apple/callback", @scheme=nil, @host=nil, @port=nil, @authorization_endpoint="https://appleid.apple.com/auth/authorize", @token_endpoint="https://appleid.apple.com/auth/token", @revocation_endpoint="https://appleid.apple.com/auth/revoke", @userinfo_endpoint="/userinfo", @expires_in=nil, @grant=#<Rack::OAuth2::Client::Grant::AuthorizationCode:0x000000011009eac8 @code="c46359e7ee0fc4df6a370c6a794cc7a9a.0.mryut.Qt7BFiM6rbza0iK5SEG4TA", @redirect_uri="https://exactly-holy-sunbird.ngrok-free.app/users/auth/apple/callback">>
12:07:13 web.1  | Completed 500 Internal Server Error in 465ms (ActiveRecord: 6.0ms | Allocations: 14572)
12:07:13 web.1  |
12:07:13 web.1  |
12:07:13 web.1  |
12:07:13 web.1  | AppleID::Client::Error (invalid_client):
12:07:13 web.1  |
12:07:13 web.1  | app/controllers/apple_signin_controller.rb:41:in `apple_callback'

I've included in the snippet above my @client variable.

Any ideas here? This is my second run (first run was with the Apple Omniauth gem) at implementing this and have been stuck for hours trying to get basic Apple Signin to work.

During the first time signing in, the Sign in with Apple API on iOS returns a realUserStatus value.
However, it is not part of the JWT.
How can we verify it?

1Iran12345

1.2.0 seems to be out and it doesn't appear to have breaking changes, though I guess you would know better!

After a successful authentication with apple, code is returned.
In the authorize url we can request additional information through the scope param.
Doing so will result in user object being returned as well.

When users login through safari though, a native window modal (keychain) takes control and does the authorize request for us.
First problem with that approach is that nonce is not passed through from our original authorize url, so we cannot use it to verify the front & back channel token.
The second problem is that when using multiple scopes, ex [:email, :name], they are encoded like this email+code.
The html rfc spec states that in query params (stuff after ?) spaces can be encoded as signs '+' and everything before with '%20'.
Apple's native popup is not aware of the '+' as an encoding method and tries to interpret multiple scopes as a single value, which is of course incorrect and ends up ignoring it altogether.

For this reason when using the plain apple sign in button in your example project through safari and the native popup appears (and intercepts the call) email & name are never returned.

When using the JS SDK provided by apple, the scope is url encoded (email%20code) and we get the information as expected. We also get the option to choose which name and email to share.

ps. The above examples were taken after revoking access to the heroku app from the apple id console, because apple gives the email & name only the first time for a new client.

Identity token verification should be possible without providing client instance. The client requires OAuth service credentials that are unnecessary when already acquired identity token needs to be verified.

Looks like the client is necessary only to verify the aud value. This value could be passed as an argument.

Motivation

The rack< 2.1.4 gem contains a security vulnerability. Updating to 2.1.4 or higher is the recommended remediation, and many applications will want to pursue.

Overview

The apple_id gem has rack-oauth2 as a dependency, pinned at ~> 1.12. The rack-oauth2gem begins support for rack>=2.1.4 at version ~> 1.13. Bumping this gem's dependency on rack-oauth2 will add support for rack>2.1.4.

Is Apple's /auth/revoke not supported? Apps submitted after June 30th 2022 may require this, depending on how Sign In With Apple is used. Thank you. Reference: https://developer.apple.com/documentation/sign_in_with_apple/revoke_tokens

In the client registration step, it says

Verify your REDIRECT_URI domain by uploading /.well-known/apple-developer-domain-association.txt to your server

I think that is only relevant for setting up Associated Domains to support either Universal Links or Shared Web Credentials. While it certainly won't do no harm, I don't think it's required for any use case of this library (correct me if I'm wrong), and thus can be removed from the wiki?

Hi!

There was a case in my rails app where the id_token from the access_token! is nil. From here, it seems it is expected if the id_token is not present in the response. My question is, in which situation this thing can happen? Thanks!

I have the example project running and I get a response after logging in but the rendered page at /session doesn't include the email address.

I did update the gem to 3.0 but the email field on IdToken is still empty.

When I call response = client.access_token!, I get RuntimeError (No Host Info). Could someone give me some pointers here?