I'm getting a little overwhelmed with all the information available to me.
Say I have a website on which I want to authenticate users and manage their profiles for cross mobile reuse. This website works closely with Amazon AWS.
How can I achieve the following combination?
Authenticate users using a wide array of providers
Not integrate each and every provider separately and manually
Use the credentials from these authenticated users to integrate with Amazon Cognito
Facts that I am aware of:
There are services out there that offer a single API to authenticate with a wide variety of providers (well known example: oneall.com).
OpenId is a standardized authentication scheme that some providers implement. But the list seems much shorter than the lists of Social Network Providers that services such as OneAll support. However, OneAll also support OpenId it seems, but I'm not sure what that means for me.
Amazon Cognito integrates a very limited list of Social Network Providers, but you have to do the groundwork yourself, Amazon Cognito only seems to known about the keys they produce
Amazon Cognito also support OpenID
Ideally I would like to use one of the Social Network Provider meta services that allow me to effortlessly add and remove login options. At the same time, I want to be able to use Amazon Cognito to link these credentials to profiles.
What are my options?
Amazon Cognito supports users logging in with Facebook, Amazon, Twitter, Digits, Google, or any OpenID Connect provider. If you want to support users logged in with another provider or with a federated provider, you can use OpenID Connect or Developer Authenticated Identities.
OpenID Connect: There are products out there that federate/broker multiple social providers and expose the federated user via OpenID Connect which have special support for Cognito including Ping Federate and Auth0 to name a couple.
Developer Authenticated Identities enables you completely control the authentication process for the user. Essentially your user logs in with your own backend (which you could use to broker social logins) and your backend makes a secure call to Amazon Cognito with an identifier that you use to uniquely identify the user to retrieve a token from Cognito. Potentially you could federate identities using this method as well. The Cognito Developer Guide has a visual showing the flow to understand the big picture and a complete guide to setting it up.
Again, Amazon Cognito already supports the most popular social providers out of the box and we have a topic for each social provider in the Amazon Cognito Developer Guide, but above is a more exhaustive list of options.
Related
Is there a way to limit use of a web app to only users who have access to a specific custom Gmail domain. e.g users must have a '#companyName.ac.uk'email address in order to successfully sign-up/create an account.
Using just Firebase Authentication, no, you can’t limit who authenticates-it just authenticates users. Controlling what kind of privileges various users are granted is an issue of authorization and that’s up to the developer to build. That being said, Firebase does offer some features that can help like auth token custom claims, server-side Functions, and Firestore/Real-time Database access rules. Which combination of these works best for you depends on how you’re building you app.
I am trying to implement sso with firebase authentication and i am trying to use without using third party like okta and wanted to know is it any workaround with this.basically the use case like this
A client wanted to build a custom SSO solution and had already chosen Firebase, based on Google’s promise to rollout SSO support in the future. The client did not want migration to any other SSO provider like Auth0 or Identity Server, or to deal with user-password migration and potential related issues. They preferred instead to use a temporary, custom solution that would store user’s passwords in Firebase Authentication.
The client had several customer portals based on WordPress Customer Relationship Management (CRM) and an existing list of users in Firebase Authentication. Each time users visited a new portal, credentials were required, and again when users followed a link from one portal to another. It was not always obvious for users that the same credentials should be used for different portals.
By default, Firebase keeps authentication context for one domain but doesn’t provide seamless SSO integration between different domains. To provide this functionality, SoftServe determined that a new Firebase service should be implemented.
Using a simple C#/WPF application and the SharePointPnPCoreOnline I can call the GetWebLoginClientContext() method which opens up a window for the user to authenticate via MFA to a given SharePoint site. From that point on I can query the SP site based on the users level of access. The convenient thing about this approach is that I don't have to register my WPF application with Azure AD, give it permissions, get a client ID, client secret, yadda yadda yadda.
Is there a library that will similarly allow me to authenticate a user via MFA so that I can access the Graph API based on their permissions without the AAD app registration requirement from a C# client application? How about a JavaScript application?
This is not possible, to access the graph api, (for a work or student account) there must be an app registration to give you permissions to those endpoints. even the "graph explorer" has a registered application.
Even with your sharepointpnpcoreonline, that likely authenticates against an app registration/service principal, its just that its microsoft trusted app registrations, so it's hiding it in the background from you. if you were to check in your azure ad enterprise applications under microsoft applications, there are various service principals for sharepoint online for example.
Long and short of it is that you need to have an app registration/service principal to access graph api endpoints. you don't necessarily need a client secret though, as that depends on your specific application and the authentication flow you choose to use in your app registration.
I understand that I can use Google Sign in button and grant access to my website only to users from my domain (using metadata tag).
My question is, once a user is logged in can I control the pages that he/she sees. For example I want some users to be admins but other users to be regular users. Each user 'type' will have access to different set of pages.
Thanks,
Shay
Google's sign-in API can only authenticate users, it can't manage authorizations. For that you'll need to either use a cloud service like Cognito (which supports Google sign-in as a federated login provider for its own temporarily-generated identity) or write your own server-side access manager that associates the sign-in token with specific permissions, and then handles the authorization of user requests.
I've been debating this with my colleagues but we have no clear solution. OAuth gurus, your wisdom is needed please!
Context:
My company "CompanyX" is exposing a set of REST APIs which are protected behind an own OAuth2 service. I have full control over the OAuth implementation.
3rd party developers use the API and OAuth to develop apps.
My company plans to develop a client-side ONLY web application for desktop and mobile browsers. Users of this app log into their account with a username/password. In the spirit of "eating our own dog food", the new web app will use the existing REST APIs and OAuth service.
Instinctively, I would have my app use the OAuth2 password grant-type.
Problem Statement:
Picture this: as a user, you press the Login button on the AppX (my app) developed by CompanyX (my company). It redirects you to a box that reads:
"AppX by CompanyX" wants to access your CompanyX data, do you allow
it?
This doesn't look right: CompanyX shouldn't have to ask the user's permission to access the data it itself manages, right? How should OAuth be used here, which OAuth grant type should be used that doesn't compromise the app secret (this is a client-only "insecure" web app) ?
Thanks
Remi