B2C SingleAccountPublicClientApplication - Create Authority Info via Dynamic Data

[photon-jasonnoe]

Hello, I'm currently implementing a B2C SingleAccountPublicClientApplication. Our system requires that the authority be built at runtime using dynamic data such as tenant name, authority host, and sign in policy to build the authority URL. I managed to get everything working with a regular PublicClientApplication, because there is a creation method provided that allows me to specify the clientID, authority URL, and redirect URI inline, and it provides back a PublicClientApplicationCreatedListener.

public static void create(@NonNull final Context context, @NonNull final String clientId, @Nullable final String authority, @NonNull final String redirectUri, @NonNull final ApplicationCreatedListener listener)

However, when I attempted to utilize the SingleAccountPublicClientApplication, it does not support the same creation method despite inheriting it from PublicClientApplication. This is because it delivers an IPublicAccountClientApplication instead of an ISingleAccountPublicClientApplication in the onCreated interface.

I am able to make this work by writing all my dynamic data to a file on the user's system, and then providing that file reference to the SingleAccountPublicClientApplication.create() method. I would rather not be writing these details to file, and instead be able to just build dynamically like the base PublicClientApplication. Please let me know if you have plans to support this.

[adambrenkus]

We're facing the same issue and would appreciate if this is resolved. On iOS this has been already possible for some time now.

[photon-jasonnoe]

I have created a pull request with a few constructor options that I believe would bridge the gap. I am open to feedback and suggestions, but this would definitely suffice in the meantime.

1861

[photon-jasonnoe]

For anyone else running into this issue, here is how I have resolved it temporarily (@adambrenkus)

I have created room tables to store my various tenant configurations that my API delivers (all the information required to create the Public Client Application). I then store these by date last used.

The PublicClientApplication creation method returns a MultiAccountPublicClientApplication (under the guise of it's inherited PublicClientApplication structure), however since I don't wish to use multiple accounts at once (but can't use SingleAccountPCA due to aforementioned issue) I instead check the room DB for a recently used tenant. If I have one, I try to construct the PCA, and then when casted to a MultipleAccountPublicClientApplication I can use getAccounts in a coroutine, grab the first account if one exists, and then attempt a silent token refresh and user grab. If the silent refresh fails, I launch the interactive login.

Again, this is a lot of messing about for something that SHOULD be plug and play once I provide tenancy. Please continue to consider my PR contribution to make this easier on SingleAccountPublicClientApplications!

For everyone else -- feel free to reach out to me if you have any questions, feedback, or concerns about my implementation and I'd be happy to discuss it at jason.noe@photon.care

[negoe]

Thanks @photon-jasonnoe for your contribution. I will discuss and review this with our team and will get back to you.

[photon-jasonnoe]

Awesome to hear! Let me know if you see any revisions or requests. It's not the most thorough implementation but it should certainly get the job done.

[adambrenkus]

@negoe any updates on this?