fusionauth-issues icon indicating copy to clipboard operation
fusionauth-issues copied to clipboard
verified publisher icon FusionAuth

Apple IdP using a mobile/desktop app

Open johnmaia opened this issue 5 years ago • 6 comments

Apple IdP using a mobile/desktop app

Description

During the past week we've being implementing Apple login on our mobile app and I have to say that, thanks to FusionAuth, this implementation was fairly easy to achieve. But we did encounter some issues along the way and I wish to share them we you because I'm afraid that our solution may break in the near future.

By reading FusionAuth's documentation I've realised that this integration was though for web apps and not for a mobile/desktop app. Nonetheless I've followed the suggested configuration steps and ended up creating a key and a services associated to my existing identifier. To configure the services I've configured a redirect_uri even though the mobile app does not use it.

After configuring the Apple IdP on FusionAuth the first issue I've encountered was that when calling the Apple IdP login endpoint I've received a BadRequestError indicating that it was missing the redirect_uri inside the data object even though this is not mentioned on the documentation. Anyway, I've set it with the same value that I've previously configured on the services and I was able to reach the next issue.

The tokens generated on a mobile/desktop app are considered invalid by FusionAuth/Apple(?) because the aud (Audience) value is set to the Apple's identifier bundle id and on FusionAuth the Apple IdP servicesId is set to the id of the services created when following the documentation. By replacing the servicesId with the identifier bundle id we've ended up getting a working solution.

I understand that FusionAuth is a solution that offers a ready to use login page, that is pretty handy on projects that do not need/want to created their custom page, which is probably the reason why the documentation is intended for those use cases. I'm ok with that, but I'm afraid that because the Apple IdP login endpoint requires the redirect_uri (even though I'm not using it nor I'm using the Apple services) we suspect that the current Apple IdP FusionAuth implementation is made for web apps only and that our solution will eventually break.

Related

  • https://github.com/FusionAuth/fusionauth-issues/issues/1248

johnmaia avatar Jul 29 '20 10:07 johnmaia

Thanks for the feedback @johnmaia .

To summarize,

  1. Update doc to indicate the required values on the /api/identity-provider/login endpoint when using Apple.This is currently missing redirect_uri.
  2. Make the redirect_uri optional so you can use this API with your own non-web based login solution. Currently with this restriction, you have to register a value with Apple and send it on this request even though you are not using it.
  3. Token issues.

Re: the token issues, can you clarify the use case and how we could update FusionAuth to work for both web and desktop? Currently we use the servicesId in the following manner:

  1. As the client_id when making a request to Apple.
  2. As the sub claim when building the JWT used as the client_secret when making a request to Apple.
  3. To validate the id_token sent by Apple to assert the aud claim is equal to the configured servicesId.

If I understand correctly, the the id_token generated when using the desktop or mobile app has an aud claim equal to the Apple bundle Id instead of the service Id? I'll have to review the Apple documentation, but when we built this, we based the id_token aud claim validation on the Apple documentation.

Perhaps there is a way for us to validate this token differently based upon the use case, or maybe we are doing it wrong.

robotdan avatar Jul 29 '20 23:07 robotdan

Doc fix: https://github.com/FusionAuth/fusionauth-site/commit/c18291fc312d90ecf170ac4ab517c1a111d62731

robotdan avatar Jul 29 '20 23:07 robotdan

If I understand correctly, the the id_token generated when using the desktop or mobile app has an aud claim equal to the Apple bundle Id instead of the service Id?

Yes, that's correct.

I understand the confusion with Apple's SSO implementation. I also have a hard time navigating/understanding their documentation. They've really used their slogan as motto (think different) :P

  1. To validate the id_token sent by Apple to assert the aud claim is equal to the configured servicesId.

Probably the solution will pass by accepting both values (service_id and the identifier bundle_id), and require at least one of them, on FusionAuth's Apple IdP configuration and validate that the aud is equal to one of them. But warning the admin that by giving only one of them will either disable web or mobile/desktop authentication.

  1. As the client_id when making a request to Apple.
  2. As the sub claim when building the JWT used as the client_secret when making a request to Apple.

I believe that Apple will probably accept either the service_id or the identifier bundle_id as the client_id and sub because they are both related:

Screenshot 2020-07-30 at 12 26 43

They actually mention here that they are both considered the client_id.

Screenshot 2020-07-30 at 12 32 48

I haven't test this, but it will probably work and solve this limitation.

johnmaia avatar Jul 30 '20 11:07 johnmaia

I understand the confusion with Apple's SSO implementation. I also have a hard time navigating/understanding their documentation.

Ha.. yes, of all of our IdP configurations, the Apple integration was the most difficult, perhaps just ahead of the Twitter documentation for OAuth v1.

The only way for us to figure out how it all went together was to read third party blog posts since navigating the Apple documentation just took us in circles.

In any case, thanks for the details, we can do some more testing and see if we can either test for both values, or come up with a strategy to handle the desktop and mobile usage.

robotdan avatar Jul 30 '20 15:07 robotdan

Any updates on this

TockaAyman-VG avatar Apr 28 '21 19:04 TockaAyman-VG

Not yet... we swamped at the moment trying to keep up with the business growth and hire more developers. :-)

I would love to get back to this one once we have some free cycles. If anyone is interested in helping to fund this effort let us know and that would help us prioritize it.

robotdan avatar Apr 28 '21 20:04 robotdan

Internal

  • https://github.com/FusionAuth/fusionauth-app/pull/162

spwitt avatar Dec 09 '22 16:12 spwitt

Hello @johnmaia and @TockaAyman-VG !

I've just finished the changes for this feature. A brief summary:

  • Add bundleId to Apple IdP config and application override
  • The Apple IdP login API will continue to use servicesId by default
  • If you specify data.isNativeApp with a value of "true" (as a string) on your request, it will validate using bundleId instead of servicesId
  • In the isNativeApp case, redirect_uri is not required on the API request to FusionAuth
    • Based on conversations here it sounds like the redirect_uri parameter is also not required by Apple from native apps. Please correct me on that point if I misunderstood.
  • You should be able to specify both servicesId and bundleId on the main IdP configuration and get rid of the duplicate FusionAuth application and IdP settings override

No one on the FusionAuth team has much experience with iOS development. Would you be interested in testing this feature using an Early Access Program build before it officially releases?

spwitt avatar Dec 09 '22 18:12 spwitt

This is available in the early access build of 1.43.0 if anyone is interested to give it a go before the general release.

https://fusionauth.io/docs/v1/tech/admin-guide/releases#early-access-program

The gist of the current solution is outlined above by @spwitt (https://github.com/FusionAuth/fusionauth-issues/issues/778#issuecomment-1344627279)

robotdan avatar Feb 02 '23 21:02 robotdan

Doc task completed. Closing issue.

spwitt avatar Feb 22 '23 22:02 spwitt