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.
Related
We have a third party company developing a mobile app and they want to call our API's. Our API is protected with Identity Server 4 which uses OpenID Connect and OAuth2. In order to access our API's would their app have to pop open a mobile browser so the user can log into our system? What if users already authenticated with the third party's identity provider? Seems like that would create a negative user experience to authenticate two different times while using the app.
My understanding is we would add their app as a client in Identity Server using the authorization code grant. Would we add their identity provider as an identity provider that our Identity Server can call?
Any help on this would be greatly appreciated. I've researched myself into a hole.
would their app have to pop open a mobile browser so the user can log into our system?
You are pretty much right on your assumptions that their app would have to somehow initiate oidc flow to allow the users of the mobile app to authenticate with the authority of your API (identity provider).
Seems like that would create a negative user experience to authenticate two different times while using the app.
It seems that this is what's holding you back. Firstly, that mobile app's identity provider is separate from your API's authority and it is important to understand that the "user" authenticated with the other identity provider means close to nothing to your API because the token has been issued by a different authority and it's not even a "user" from your user base.
My understanding is we would add their app as a client in Identity Server using the authorization code grant.
Yes, but check also Authorization Code grant with PKCE which adds extra security measures.
Would we add their identity provider as an identity provider that our Identity Server can call?
Yes, you will need to do that, but this is just a start of the things you would need to do to achieve what you are looking for. Because you already have Identity Server 4 in place, I assume your systems already have an established user base, therefore if you just redirect to the external identity provider, once a user authenticates there and the token is issued back - that kinda means nothing because you don't have any kind of mapping from the user of the third party system to the user of your system.
There is pretty much nothing out of the box in Identity Server 4 that will help you with this, but one way to tackle this is to implement some sort of account linking mechanism, where the users would first have to "link" their account in your system with the account in the third party system. With account linked, you would have means to issue claims related to your system.
Identity Server 4 absolutly has out of the box solutions for this. If they didn't, what would be the point calling themselve a OAuth 2.0 framework?
You do not need to initiated a oidc flow like stated. What does that even mean anyway? oidc is connection protocol, not a flow. Flows include hybrid, implicit, clientcredential, etc.
You could obtain an access token for your 3rd party app a number of ways all use the token endpoint built into identity server 4 specifically for creating access tokens The most common is using the ClientCredential flow, where you gain a bearer token by hitting the identity server 4 token endpoint passing the client_credentials grant type with the ClientId of the client they want to access, a shared secret supplied by you, and the api scope they are attempting to access.
Another option is you could create a user for this client on Identity Server 4, then gain an access token using the ResourceOwnerPassword flow by hitting the token endpoint passing the password grant type, clientId, username, and password, again along with the api scope they want to access.
For information on how to do all of the above check out his link. It will help you on your way.
http://docs.identityserver.io/en/latest/endpoints/token.html
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.
Should be a simple matter of registering the app in the IBM Cloud and providing callback URIs for authenticating the user and returning control just like login with google or login with Amazon.
But I cannot seem to find the exact flow of steps involved.
--prasanna
I think the service you are looking for is App ID.
When you are developing a web application, you can use the App ID web flow to securely authenticate users. Users are then able to access your server-side protected content in your web apps.
App ID uses the OIDC authorization code flow to securely authenticate users. With this flow, when the user is authenticated, the app receives an authorization code. The code is then exchanged for an access, identity, and refresh token. In code exchange step the tokens are always sent via a secure backchannel between the app and the OIDC server. This provides an additional layer of security as the attacker is not able to intercept the tokens. These tokens can be sent directly to the web server hosting application for user authentication.
App ID interacts with identity providers by using multiple protocols such as OpenID Connect, SAML, and more. For example, OpenID Connect is the protocol that is used with many social providers such as Facebook, Google. Enterprise providers such as Azure Active Directory External link icon or Active Directory Federation Service External link icon, generally use SAML as their identity protocol. For Cloud Directory, the service uses SCIM to verify identity information.
Read this blog post for using a custom identity provider
For an in-depth understanding of the flow, you can refer to this link
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.
We are in a complex authentication environment and need to support authenticating against a number of disparate sources in applications we are developing. Since we don't want to be duplicating authentication code all over the place, we are looking at wrapping the various authentication sources with a single OpenID provider, and then having the applications all depend on that service.
The sources we have to allow authenticating against are things like Active Directory Username/Password, Kerberos, generic LDAP, external OpenID providers, etc.
For example, in the Kerberos case, when the user hits the OpenID provider's authentication page, if (s)he can be authenticated with Kerberos, and has already given permission to the requesting app, the user would be transparently authenticated as if a password was entered and passed back to the requesting app.
So, the question is, can we have create an OpenID provider that handles authenticating through all of these various methods? Does the provider have to implement how it authenticates the users in a specific way?
OpenID 2.0 specification do not specify how to authenticate users at the OpenID Provider there for it is vendor specific. So my answer is Yes, you can have an OpenID Provider that handles authentication through all those methods but you have to figure out how to, for example how to present the Kerberos tickets to the OpenID Provider is up to you to decide.