Aaron Parecki

😂😂😂 Yep I use it in my book and I've also been using it for testing out redirect URIs in workshops and stuff!

verify where? The unique ID comes back in the ID token not the access token. (also happy to take this to DM)

Another question, if there is no `user_info` endpoint, what are the access token and refresh tokens for?

Progress! I now get the screen which lets me edit my name and choose the email to share. I only see that the first time, all subsequent requests show a confirmation only.

Still no luck actually getting the email address back in the ID token though.

I will go test this out with new app credentials though to confirm. Thanks for the lead!

interesting. well the bug is that I have *never* gotten it, because I didn't request it the first time, and now I can't request it ever again.

Just verified again, and I don't get back name or email address when I request "name email" scope.

I did find a bug where apparently Apple is ignoring the "scope" parameter after the very first time you authorize an app though, so could be related.

Brilliant, thanks for the info!

Have you been able to successfully request name and email scope yet? It wasn't working in my testing.

Thank you! You helped me track down a deeper problem!

It turns out that you're right, having `scope` in the request causes Apple to return a 500 server error when confirming the login on their site before it redirects back to the app.

**However**, the really weird part is that Apple apparently completely ignores the `scope` parameter the second time you log in to an app, so there is no error.

The very first time I logged in to an app while testing this code I didn't include the `scope` parameter, so it worked. Then I added the parameter to see if I could get it to return an email address, and it didn't. It also didn't fail, because I had already logged in once.

I was having trouble logging in with a new App ID I created, and this is the reason! I just tried removing the scope from my attempt and now I'm able to log in with new App IDs.

This is very inconsistent behavior by Apple, so I hope they fix it later.

Some people like to use JWTs for access tokens or other self-encoded mechanisms. There are definitely trade-offs.

echoing the rest of that conversation, I think the larger point is the inverse.

If you *only* post your thoughts about decentralization on platforms that actively work against decentralization and cause real-world harm to people, then maybe it's okay to ignore those thoughts.

if your access tokens are just a reference to a record in a database (the hotel key is just a number, and the doors look up access info in a central server), then you can update the roles in the existing token.

The analogy continues... with JWT access tokens, that's like encoding access data into the hotel key card. You'd have to go back to the front desk to get a new card.

The answer is it depends on how your access tokens / hotel key cards are implemented!

I haven't found it yet. I wouldn't be surprised if they just don't have that endpoint

The docs are also wrong in a few places. Happy to provide details via DM or email.

I have so many questions for you! I was able to create a proof of concept, but would love to know some of the missing details. The current documentation is not complete enough to make a working app, I had to guess things based on my knowledge of OIDC.

https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple

you joke, but: https://indieweb.org/2018/D%C3%BCsseldorf/gdpr

Yes that is my understanding reading their guidelines. Of course this remains to be seen how it will play out in practice.

It's working with the first app I registered in the portal, but hasn't worked with new app IDs I've made since! I'm guessing some weird Apple but that they'll probably fix soon. This is all clearly very early beta right now.