Determine Social Provider Login Support (Facebook, Google) with StaticWebApps & App Service

[seantleonard]

Evaluate whether social providers include roles in their access tokens, i.e. via a role claim.

• If role claim(s) are included:
  • Can an end user can arbitrarily add themselves to roles or is that capability limited to FB app/enterprise admins?
  • If users can arbitrarily add themselves to roles, ensure we do NOT honor those roles to determine access in DAB engine and see whether SWA/AppService passes those roles through in the EasyAuth payload.
  • If just enterprise admins can manage roles/role assignments, no issues.
    • Check whether SWA/AppService passes those roles through in the EasyAuth payload. If not, developers must manage roles through SWA Azure Function Integration.
• No Role claims included:
  • Developers must manage roles through SWA Azure Functions (preview) Integration.

[jarupatj]

What do you mean by inject role? Do you have example? If we are using JWT as auth method, would Twitter, FB, Google set the role then?

[seantleonard]

When social provider mints an access token, it may include roles in the token if the provider supports roles, we should not honor those. This would also require enumerating all providers we'd want to eventually support to see what their token contents are. Social providers would not be an "all or nothing" support structure, it would need to be provider by provider because while they do provide tokens that show the user authenticates, the token contents (claims) may vary.

Since we've only tested with azure ad, we know azure ad will securely provide roles as role assignments are made in an administrative context.

[ayush3797]

@Aniruddh25 , FYI, moving it to Oct2022 milestone.

[ayush3797]

Needs discussion. Moving to Nov22.

[seantleonard]

SWA Configure Providers: https://learn.microsoft.com/en-us/azure/static-web-apps/authentication-custom?tabs=twitter#configure-a-custom-identity-provider

• Facebook: Looks like Login With Facebook requires an App be created from the Facebook Developer Dashboard. From there, an administrator may add and assign roles to users which would mitigate the concern that users could add themselves to any role, HOWEVER, the openid connect document below does not show that role claims are supported in FB access tokens. This should be tested and demonstrated with a sample.
  • https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-facebook
  • https://www.facebook.com/.well-known/openid-configuration/

    "claims_supported": [
    "iss",
    "aud",
    "sub",
    "iat",
    "exp",
    "jti",
    "nonce",
    "at_hash",
    "name",
    "given_name",
    "middle_name",
    "family_name",
    "email",
    "picture",
    "user_friends",
    "user_birthday",
    "user_age_range",
    "user_link",
    "user_hometown",
    "user_location",
    "user_gender"
    ]

• Google: Guidance from this StackOverflow thread, you can use the OpenID well known config endpoint to know what claims are possible from a provider.
  • https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-google
  • https://accounts.google.com/.well-known/openid-configuration shows the following claims (no roles related claim):

    "claims_supported": [
    "aud",
    "email",
    "email_verified",
    "exp",
    "family_name",
    "given_name",
    "iat",
    "iss",
    "locale",
    "name",
    "picture",
    "sub"
    ]

[Aniruddh25]

Only need test to validate this.

[Aniruddh25]

Moving to the next milestone since this is test only.

[Aniruddh25]

@ayush3797 , @seantleonard, whats the latest on this issue? do we plan to do the testing in Jan2023?

[seantleonard]

I would suggest we defer support for social identities (FB, Google, etc), to identity providers like Azure AD, Okta, and Auth0. Those identity providers provide support to connect with social providers to facilitate account linking, consolidation, and token augmentation such that an access token with consistently provided claims can be provided to DAB.

[aaronpowell]

I've got an example of how to setup SWA + Auth0 and SWA + Okta if they would be of use.

When it boils down to it though, the SWA backends don't know what the identity provider is, they only see the token provided.

[seantleonard]

Yeah those would be helpful. I envision social provider support to be handled by either SWA, AppService, or azureAd/okta/auth0 directly.

Essentially something like azure ad b2c lets users sign in and register accounts in a b2c tenant with their social provider. Behind the scenes b2c creates and manages its own user record and the user record has attributes which associate the social media account’s guid to the b2c account.

ultimately, DAB would not have any config where social provider metadata is set

[aaronpowell]

SWA is using the same engine as AppService, EasyAuth, so that might make it easier for testing as you could host DAB in AppService, enable EasyAuth and inspect what comes in as the payload*.

*In theory - I've never tried that, I just know that that is all the plumbing.