Post not yet marked as solved
It would also work to have separate Services under one Application. Each SIWA service maps to its own client_id and set of redirect urls. But how does the iOS app select which service to use when there are multiple under the same Application?
Post not yet marked as solved
Thanks @sudhakar19 for the response. Can youi clarify what you mean by "domains in which web applications are hosted"? If we do not verify a domain at all, what will fail besides emails to relay addresses, and at what point?Second question: We would also appreciate some guidance around subdomains. Our app uses multiple subdomains and it's not clear whether we should verify all of them, just one of them, or the top-level domain.
no really, can we get some official guidance on this please?
Conventional wisdom recommends against using emails as unique identifiers. They can change and more importantly they can change ownership. The id token comes with a "sub" string that uniqely identifies the person. Storing that and using it as a key would be safer from a security perspective.
Post not yet marked as solved
Thanks Dima, the problem is that if user creation fails for some downstream reason we do not have a way to gracefully recover. The user will be orphaned until they go into iCloud settings and revoke the app permission to force a fresh login.Conventionally the ID token would contain all in-scope identifying information: name and email in this case. I would also expect to see the real-user confidence value there. Information passed outside the jwt is not signed so cannot be trusted and so not very useful.
Thanks! My only concern is that the way things are changing it doesn't feel safe to code against a GET flow until it is documented as supported.@Apple can we please document and support the GET redirect-flow to help with Android clients and others who don't handle POSTs well?
@tdh42 where do you see that form_post is not required?
Post not yet marked as solved
Hi Redth, QQ:> yes, the auth code is returned in the url fragment of the redirectHow did you manage this? There's nothing of note in the url or query string in my experience so far.
Post not yet marked as solved
The use of the form post response mode to pass the token back to the client complicates things. Intercepting the outgoing post with an intent filter will give you the url but not the post body. Android apps have two options that I have found: (1) use a webview with injected javascript to scrape the form data as it is posted or (2) a server-side solution, where the android client does not manage apple tokens at all.Javascript injection is basically exploiting a security vulnerability in the WebView and not recommended by anyone, but it's there as a last resort. We're going with a server-side solution for now and keeping eyes and ears open for a third option.
I think the idea of including user name/email in the JWT as Aniwat mentioned above would get us out of the woods
Saw this for the first time today, there are now four items in the posted form data on successful login: state, code, id_token, and *user*. User has firstName, lastName, and email in a json blob.Should we be concerned about replay attacks, since the user info is unsigned? In other words, if a nefarious actor replays a previous post but changes the "user" to something else, is that detectable?
