Apple sign-in troubles with use case

Hello,

I'm currently struggling to figure out how I can make Apple sign in work with my app configuration. Maybe I'm just dumb, but I really can't figure out what I need to do to make it work.

So I have a Next.js app setup server-side rendering my React frontend, and on a separate server, I have a Node.js (specifically Adonis.js) backend/api which I use to handle auth and sessions.

I have both Facebook and Google OAuth2 logins setup and working perfectly, where I'm receiving a code as a query param in my callback url to my frontend, which the client then sends that code to my backend/api, which uses that code with the provider (FB or Google) to get their email, name, and any other data I could use to prevent the user from having to add later, and either create the user and log them in, or just log them in if they already exist using cookies. I don't need any sort of write access to their third party account, or anything more than reading their name and email so they don't have to enter it themselves, and so they don't have to enter a password on my site.


There are 2 different questions I have. (and if there is a solution to the first one, it would make my life so much easier ha..)
  1. If I use these query params similar to how I would with Google or Facebook:

Code Block
response_type: 'code',
client_id: Env.get('APPLE_APP_ID'),
redirect_uri: 'https://example.com/auth/apple/callback'
state: '',
scope: '',
response_mode: 'query'

And I get redirected back to my frontend with the code in the url params, and I send it to my API like I do with Facebook/Google, is there any endpoint with Apple's system that I can use that code to request the user's email and name from?

2. From reading through doc after doc, and it still being fuzzy, I'm thinking I may need to use the form_post response mode kind of like this?:

Code Block
response_type: 'code id_token',
client_id: Env.get('APPLE_APP_ID'),
redirect_uri: 'https://example.com/auth/apple/callback',
state: '',
scope: ['email', 'name'].join(' '),
response_mode: 'form_post'

My impression is that it would post a token, and the user data to my callback url, and that I can get the user's email and name from the user's first request and attach the token received to the user in my database. I just do not for the life of me understand how I could use this pattern with how my app is setup. Would I have to have a post handler and a page setup on the same route (I don't even know if Next.js allows something like that), and then from that, I send that data to my backend server and create the account with the data received? Even if all that worked, I don't think I would be able to set the user's session since I rely on the request being made from my frontend to my backend utilizing the set-cookie header.

Please let me know your thoughts, input, or clarifications.

Thanks,
Brody

Replies

@brodynac, sorry I know this 5 months old, but I'm in the same case, did you find any solution that work for you ?

  • You all are overcomplicating things. Apple for the most part abides by the Oauth standard. Without messing around with things too much, the default response_type for Authentication Request is {code, id_token, state, user}. You can parse user for the PII you want.

    You set response_mode to form_post so expect a POST request containing Authorization Response parameters. After that you can validate and exchange the code. Store user information and the server can execute a redirect to the user. Like I said, Apple’s implementation is nearly the same as everyones’s. The only difference is they go out-of-spec and include a user struct.

Add a Comment

You all are overcomplicating things. Apple for the most part abides by the Oauth standard. Without messing around with things too much, the default response_type for Authentication Request is {code, id_token, state, user}. You can parse user for the PII you want.

You set response_mode to form_post so expect a POST request containing Authorization Response parameters. After that you can validate and exchange the code. Store user information and the server can execute a redirect to the user. Like I said, Apple’s implementation is nearly the same as everyones’s. The only difference is they go out-of-spec and include a user struct.