Federation identity are like sign up with Google, or sign up with Facebook. I want to migrate from Auth0 to Azure, but the problem is I can't find any proper documentation that explains what happen to those users who signed up using their Google or Facebook account.
There are good documentation for username and password users, but there is not anything special for federation identity users.
Does anyone know how to migrate them?
I have the same question for Amazon Cognito and other alternative services
This is not always straightforward, because some IdPs issue a different UUID per Application Registration. If you can re-use the exact same Application Registration at Facebook, for example, with AAD B2C, then this can be fairly easy.
There is an example here:
https://github.com/azure-ad-b2c/samples/tree/master/policies/link-local-account-with-federated-account
All you need to do is pre-create the Local accounts in AAD B2C, and provide the expected UUID from the federated IdPs token to the Local account user object in AAD B2C. AAD B2C can then link the account when the user comes in with that Facebook account.
Related
I am building an SSO system for android where I am the identity provider. And I want users to sign in from my app that will automatically log them in to google workspace (or any other enterprise application e.g salesforce). I cannot figure out what and how to send identity values from my Idp to Google workspace.
This can't be done this way round. When a user signs in to your app she can't be automatically signed in to any other application. The options that you have are:
When a user signs in to your application you can ask Google for an access token. As part of your sign-in process, you can run an OAuth flow against Google Authorization Servers and ask for proper permissions. This will allow the user to additionally log in to their Google account, consent to release information to your app and you will then get an access token that will enable you to call Google's APIs. This way your users will have to log in twice (both to your app and to Google).
You can rely on Google to log users into your app. So, Google will be the OIDC Provider and your app will only be the client. People will log in to their Google account, and you will get an ID token in return. You can use the data from the ID token to create user accounts and sessions in your app.
In the first case, you will want to have a look at OAuth flows, like the code flow. In the latter, you will need OIDC flow, e.g. the OIDC code flow.
We have a SPA web application that supports OpenID Connect login from external Identity providers. Our application supports different user types (roles). We want to support Sign in with Google using Google Identity service (https://developers.google.com/identity/protocols/oauth2/openid-connect) but the Access Token seems to be for Google APIs only (we want to protect our own APIs). The ID Token is a JWT we can validate, but there is nothing in the claims we can use for Authorization.
Is it possible to add custom claims to the Google ID token that we can use for Authorization?
From the link above...
This document describes our OAuth 2.0 implementation for authentication, which conforms to the OpenID Connect specification, and is OpenID Certified
I guess this means they ONLY support Authentication and not Authorization? Is this true? Or is there some other Google service we need to use to get user roles (Google Cloud IAM, etc.)?
How does Google expect us to Authorize users they Authenticate?
To get control over what the tokens contains, then my recommendation is to add a separate identity provider in-between your applications and Google. In this way, your applications only need to trust your local provider and it can provide the tokens that you need and you can add additional user information/claims to the tokens.
Just like this picture tries to show:
We have a .Net 6 website that integrates with Azure AD B2C using OIDC. Login and registration for the website are defined in custom policies in the Azure AD B2C tenant. Azure AD B2C returns a claim that we use for user creation and login for existing users.
The client would like the website to integrate with another platform that supports SAML SSO to Azure AD B2C. Basically, if users are signed in to the website, and by extension signed into Azure AD B2C, and they click a link on the website to take them to the other platform then the user should be signed into the other platform.
My question is if we can mix OIDC and SAML in the custom policies so that logging into the website logs the user into the other platform or does it need to be either OIDC start to finish or SAML start to finish.
I have looked into the Microsoft documentation and it explains how to integrate Azure AD B2C with either OIDC or SAML but I couldn't find anything related to integrating Azure AD B2C with separate platforms that use different protocols.
Any help is greatly appreciated.
I am not sure if understand your use-case correctly - are you trying to onboard external partner as identity provider? And their identity provider uses SAML2 protocol?
If yes, you can look at this official page - https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-generic-saml?tabs=windows&pivots=b2c-custom-policy
Basically you need to use custom policy. In a nutshell, custom policy orchestration flow redirects to identity provider, user authenticates with its own credentials. If successfully, the idp issues SAML token, redirects back to B2C.
And then you can process/transform those claims in SAML token, even create reference/federated user in your b2c (add your own attributes/claims in B2C user management portal) and send claims as JWT token back to your app.
Peter
We are planning to setup three applications, two of them are based on WordPress, and third one is based on Magento. We will deploy these three apps on AWS. We are looking for a tool to centralize the management of all the users for these three apps. We could grant different privilege and allow the different users have different right to these three apps. So, we should choose AWS Cognito or SSO?
You can use both if you go with cognito route. Cognito User pools handles your user management (registration, login, granting tokens) while Cognito Identity Pool lets you use any of the identity providers including user pool to exchange tokens for temporary aws credentials based on what role you have attached to the group of users.
Identity pools also accept SSO with 3rd part authentication providers (federated identity). You can sign in users on your user pool using social identity providers (facebook, google, amazon) or create one using Auth0.
AWS Cognito is the right fit for your application. AWS SSO is essentially a layer between active directories and services like Cognito or Firebase. AWS SSO helps in delegating access to AWS services and provides SAML/Oauth gateways connected to the active directories.
AWS Cognito on the other hand, allows you to easily integrate your login systems with any auth providers like AWS SSO, Okta, Auth0 and social media channels too. Hence, definitely considering your requirements, AWS Cognito user pool is the best fit.
I have the following question about fusionauth. Is this service itself an identity provider or is it necessary to configure an external identity provider such as OpenId or SAML?
FusionAuth is a complete identity provider as well as a service provider. This means that you can store all of your users in FusionAuth and have them authenticate directly.
You can also use FusionAuth to log users in via other IdPs such as Google, Facebook, Twitter, GitHub, Active Directory, etc. This is called federated login and FusionAuth will handle reconciling user accounts.
Within FusionAuth, you can create an number of Applications, which are just resources a user can log into. Using FusionAuth as the identity provider via OAuth, OpenID Connect or SAMLv2, you get single sign-on for free. The UI for FusionAuth's login pages are also themeable, so you can make it look like your brand easily.
Finally, FusionAuth provides a complete authorization system as well. Each Application can define any number of roles. You then create a UserRegistration, which is a User, an Application and zero or more roles the User is granted for that Application.
Feel free to check out our documentation here: https://fusionauth.io/docs/
It provides a bunch of detail on all of these pieces.