Base Scenario
There is a user in Firebase Auth with userID 1234 and email user#email.com with an additional facebook provider linked.
Signing in with an OpenID Connect Provider
Create an OpenIDConnect Provider within Google Cloud Platform's Identity Platform
Use the newly created provider to sign in with the email user#email.com
Result: You'll get an auth/account-exists-with-different-credential error with the credentials sent back. This is the expected behavior.
However:
Signing in with an SAML Provider
Create an SAML Provider within Google Cloud Platform's Identity Platform
Use the newly created provider to sign in with the email user#email.com
Result: The SAML provider is automatically linked to the original firebase user with the userID still 1234. However, it also replaces the previously set Facebook Provider.
Is this a known issue? Am I doing something wrong? The real issue is the replacing of the providerID, but the inconsistencies seem troubling.
-- UPDATE --
Authentication is performed for both OIDC and SAML similar to these docs:
https://cloud.google.com/identity-platform/docs/how-to-enable-application-for-oidc
Specifically:
let provider = new firebase.auth.OAuthProvider(providerID);
this.firebaseApp.auth().
signInWithPopup(provider)
where providerID is either saml.someprovider or oidc.someprovider
Related
I’m reading the “Learn the Basics” article on Auth0 here. It talks about how Auth0 sits between the identity provider (such as Facebook or Google) and the app. The identity provider provides users to Auth0, which in turn provides the same users to the app. The difference is that while the details of the connection between the identity provider and Auth0 depends on the implementation of the identity provider, the details of the connection between Auth0 and the app stay the same, so Auth0 provides users to the app while hiding the details of the implementation of the identity provider from the app. My question is: is this the main point of Auth0? To successfully receive users from the identity provider no matter what the identity provider’s implementation and then forward the users to the app in the same consistent way every time?
Auth0 provides many different features. It can act as the service provider like you describe, or it can act as the identity provider and host the user data. In addition to issuing tokens after authentication, the platform can provide features like role based access control, M2M authorization, and custom hooks and rules based on authentication events. In addition, other features such as multi-factor auth, password reset, email verification, can all be achieved in a turn-key manner using Auth0.
I'm trying to authenticate users with the SAML protocol.
So far I have two applications in two different identity providers (Auth0 and OneLogin) to test. I also have my service provider.
What I'm trying to do is authenticate users without redirecting them to any Identity Provider login form.
Something like this:
The user tries to log in to my application (made in React)
My server provider receives the request made by the user and sends
the credentials (username and password) to an identity provider
using the SAML protocol.
The identity provider validates the credentials, if they are
correct, return a SAML assertion to my server provider; otherwise,
it will return an error.
Depends on the identity provider's response if the content is sent
to the user or not.
I know that it is not the intended use of SAML, but I want to know if there is a way to do it and how it will be possible.
Any help or advice will be well received, thank you.
That's not how SAML works and I'm not aware of any SAML identity providers that accept the user's name and password.
It is possible to include the user's name in the SAML authn request sent to the identity provider but there's no provision for including a password.
I think there are a number of security considerations if you were to prompt a user for their credentials for one web site (ie the identity provider) at a different web site (ie service provider).
Using SAML SSO, if the user isn't already authenticated at the identity provider, it will prompt the user to login.
This was hard to find so I'll add it here in case anyone needs it.
When adding google sign in as a cognito authentication provider for both Android and iOS I need to use the OpenID rather than Google+, but when adding in google as an OpenID I couldn't find the provider URL in google's documentation
The provider URL is hardcoded accounts.google.com for any credential you create, and add all the clientIDs under Audience.
To add google sign in to Cognito for both iOS and Android:
Go to IAM -> Identity providers
Create a provider
Choose OpenID Connect
In the provider url write https://accounts.google.com
In Audience write one of the app's client_id that you can get from the credentials console
Go back to Cognito:
Under authentication providers go to OpenID
Select accounts.google.com
I'm building an API that my public mobile app (xamarin forms) will call to get information. However to delimit the users of the API to just my app for security reasons, I want the public mobile app (xamarin forms) to pass a key to be able to call the API. Is basic authentication the best option then ? Or is there another approach ?
You can use any Auth based mechanism in your web api project. The best would be the latest Identity 2.0 using Owin.
OAuth is an open standard for authentication, and enables a resource
owner to notify a resource provider that permission should be granted
to a third party in order to access their information without sharing
the resource owners identity.
In your Xamarin client project (mobile app) use the Xamarin.Auth SDK to authenticate your users. It provides many features and also helps you to scale and use Social authentication as well.
Xamarin.Auth is a cross-platform API for authenticating users and
storing their accounts. It includes OAuth authenticators that provide
support for consuming identity providers such as Google, Microsoft,
Facebook, and Twitter.
The authentication flow when consuming an OAuth identity provider is as follows:
The application redirects a browser to an identity provider URL. The
URL query parameters indicate the type of access being requested.
The identity provider handles user authentication, and returns an
authorization code to the application.
The application exchanges the authorization code, client ID, and
client secret for an access token from the identity provider.
The application uses the access token to access APIs on the identity
provider, such as requesting basic user data.
The application uses the OAuth2Authenticator and OAuth2Request classes, provided by Xamarin.Auth, to implement the application side of the authentication flow.
The detailed explanation of Authenticating Users with an Identity Provider
Using the Xamarin.Auth component for authentication implementing is available here.
I am building a muli-tenant saas(software as a service) architecture. I have to build the authentication system for the system.
From what I have studied, I think I need to the build the authentication system based on OAuth2.0 and the bearer token with JWT tokens.
After reading a lot about OAuth2.0 of how to build an OAuth2.0 server I still didn't understand the full concept of OAuth and also have confusion about whether I need it or not or I need some other Authentication system.
What my system need is we will provide an SDK to all our customer and each client will have an Application Id and a secret key using the SDK client will connect to his application present in our system.
The application ID will map the customer to his application present in our system and the client secret key will authenticate the client inside the application.Do I still need to build an authentication system based on OAuth2.0 or can I build my own authentication system based on our need?
What are the use cases of OAUTH2.0 and when we won't need it to implement?
First, as clearly indicated in OAuth authentication
OAuth 2.0 is not an authentication protocol.
Authentication in the context of a user accessing an application tells an application who the current user is and whether or not they're present. A full authentication protocol will probably also tell you a number of attributes about this user, such as a unique identifier, an email address, and what to call them when the application says "Good Morning".
However, OAuth tells the application none of that.
OAuth says absolutely nothing about the user, nor does it say how the user proved their presence or even if they're still there.
As far as an OAuth client is concerned, it asked for a token, got a token, and eventually used that token to access some API. It doesn't know anything about who authorized the application or if there was even a user there at all.
There is a standard for user authentication using OAuth: OpenID Connect, compatible with OAuth2.
The OpenID Connect ID Token is a signed JSON Web Token (JWT) that is given to the client application along side the regular OAuth access token.
The ID Token contains a set of claims about the authentication session, including an identifier for the user (sub), the identifier for the identity provider who issued the token (iss), and the identifier of the client for which this token was created (aud).
In Go, you can look at coreos/dex, an OpenID Connect Identity (OIDC) and OAuth 2.0 Provider with Pluggable Connector.